> On Jan 25, 2016, at 08:04, Michael Dickens <michae...@macports.org> wrote: > > We've had this discuss before, how to do C++11 for libstdc++ and libc++. > > The cxx11 PortGroup implements C++11 compliance for libc++ only. It > errors out when using libstdc++. > > What Mojca is asking is whether we can add an implementation for when > using libstdc++
"libstdc++" means /usr/lib/libstdc++.6.dylib, and it doesn't support C++11, so
it is not possible to use the system libstdc++ for C++11 code. I don't think
we want to start supporting people using ${prefix}/lib/libstdc++.6.dylib from
libgcc as that is quite untested and aiming for a world of hurt.
> , and I am on board with agreeing on how to do this
> change. It won't be perfect, since using libstdc++ has issues & will
> require selecting a default compiler for building that is C++11
> compliant; and, MacPorts provides no good way to add whitelist options
> beyond variants in this case. Variants are what we used to do for
> selecting a compiler suite, e.g., for various math ports.
>
> I see no need to have port-by-port intervention; either one is using
> libc++ or libstdc++, depending on host OS and user-select options. If
> using the former, then just do what the cxx11 PortGroup does right now.
>
> If using the latter, then do something like the following -- which I
> admit is not perfect, but it should work for most ports:
> {{{
> # *clang* when using libstdc++ do not seem to support C++11;
> # C++11 support seems to need GCC 4.7+ when using libstdc++;
> # could use C++0x support on GCC4.[56], but just ignore it since
> # there are newer compilers already in place as defaults.
>
> # Blacklist GCC compilers not supporting C++11 and all CLANG.
> # This is probably not necessary, but it's good practice.
>
> compiler.blacklist-append *clang* {*gcc-3*} {*gcc-4.[0-6]}
>
> # and whitelist those we do want to use. wish there were a better way.
> # these will be used in the order provided.
>
> compiler.whitelist macports-gcc-5 macports-gcc-4.9
This is surely not what you want. This will cause the build to use
${prefix}/lib/libstdc++.6.dylib. I could see this being useful for 10.5 and
earlier or ppc builds (because libc++ doesn't work on those platforms), but we
don't really support those platforms any more anyways. You might as well use
the more-tested path of using libc++ and a macports-clang compiler in these
cases.
To be clear, setting configure.cxx_stdlib to "libstdc++" means
/usr/lib/libstdc++.6.dylib, it does not mean use any libstdc++ available. The
macports-gcc compilers don't quite work well for this scenario. If you really
want to support this, we'll need some new option for this (maybe
macports-libstdc++), and dependency tracking will become quite difficult.
> }}}
>
> My US$0.02. - MLD
> _______________________________________________
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
