Handling C++11

Mojca Miklavec mojca at macports.org
Wed Jan 18 16:15:07 UTC 2017

On 18 January 2017 at 04:43, Marcus Calhoun-Lopez wrote:
> I think perhaps I am not being clear in what I am proposing.
> Currently, if cxx_stdlib is equal to libstdc++ then the cxx11PortGroup returns an error and the port does not build.
> I am simply proposing that instead of returning an error, the port build instead.
> In other words, the change is meant to respect whatever value cxx_stdlib is.
> I am not proposing any changes to anyone’s configuration.
> I am not proposing any changes to the buildbots.
> If cxx_stdlib is equal to libc++, the end user would see no changes, not even revbumps.
> If cxx_stdlib is equal to libstdc++, the only change would be that ports that didn’t build before would suddenly start (hopefully).
> Please forgive me if I am not understanding the concerns, but this change is meant to affect *only* ports that are currently not building at all
> for users who have elected to have cxx_stdlib be equal to libstdc++.

The only thing that most of us (that is: me included) don't understand
is whether all "C++11 ports" would actually work flawlessly under such

To add to explanation on one particular example.

Octave currently requires C++11 to build. Let's assume that the user
has < 10.9 without switching to libc++ globally. Marcus now decided to
build octave with gcc6 and that apparently works. I think his belief
is that if we add
(or something similar?) to the build flags, then the binaries won't
crash like it would generally happen when mixing different stdlibs.

I was strongly convinced that mixing stdlibs (the default one and the
one that comes with gcc6) was absolutely forbidden, but if adding a
few flags can make the stdlibs "compatible", this might be a huge
advantage that would let us build quite some ports on older OSes
without switching to libc++. (I'm not 100% sure if that is in fact the
case, but it might be worth investigating.)

(That said, I would still love to see libc++ buildbots in action as one
of our highest priorities. But that's a different issue anyway.)


More information about the macports-dev mailing list