Handling C++11

Chris Jones jonesc at hep.phy.cam.ac.uk
Thu Jan 19 21:04:57 UTC 2017


For me, the better approach is to

1. On systems where the default system compiler is clang and thus uses libc++, when neccessary (such as c++14, 17, .... support, which over time will become as much of an issues as c++11) use one of the macports clang compilers that works on that platform and provides the required features.

2. On when neccessary, for instance very old systems that are based on libstdc++, either deploy the libc++ port solution by default, or.... just wait for the need to support these old systems to naturally dissipate.

I don't think we should, under any circumstances, but making the use of gcc to build c++ ports a standard practise.


> On 19 Jan 2017, at 8:32 pm, Marcus Calhoun-Lopez <mcalhoun at macports.org> wrote:
> I do not know if this helps with your concerns or not, but in the current proposal, _GLIBCXX_USE_CXX11_ABI is only set to 0 for
> macOS prior to Mavericks, where libstdc++ is the default.
> So _GLIBCXX_USE_CXX11_ABI is being used as it was intended, as a mechanism to facilitate transition.
> -Marcus
>> On Jan 18, 2017, at 2:15 PM, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
>> Set the ABI controls whether or not you compile using the new c++11 standards compliant implementations of string and list. If you set the ABI back to 0 then yes, you can then mix different std libs. But you are not strictly c++11 compliant. For that reason i do not think its a path we should be looking at as a general 'fix' for the stdlib issue. 
>> Chris

More information about the macports-dev mailing list