Hi, 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. Chris > On 19 Jan 2017, at 8:32 pm, Marcus Calhoun-Lopez <mcalh...@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 <jon...@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 >
