Changing default cxx_stdlib to libc++

Kenneth F. Cunningham ken.cunningham.webuse at gmail.com
Mon Mar 12 22:26:51 UTC 2018


On 2018-03-12, at 3:42 PM, Mojca Miklavec wrote:

> On 12 March 2018 at 22:32, Michael wrote:
>> On 2018-03-08, at 9:32 AM, Ken Cunningham wrote:
>> 
>>> Thank God.
>>> 
>>> 10.6.8, agree.
>> 
>> So PPC machines will not get this upgrade?
> 
> PPC and libc++ don't particularly like each other.

True. It is quite possible to make libc++ with PPC slices on Intel 10.5, and copy that, and a few other bits, over to a PPC machine. It works, for the most part.

It is also quite possible to build clang-3.8 for PPC, and it links against this libc++ quite effectively.

But there is a problem with handling c++ exceptions with this setup. And no thread_local support. And … we don't even know the rest yet.



OTOH, gcc6 builds almost everything, and has no problems with exceptions or thread_local storage.  

So gcc6 is presently the path of least resistance for PPC, at least until I learn enough about compiler debugging to figure out how to make the problem with exceptions work with clang on PPC, or until someone else with the skills already finds an interest in this dying hobby platform.

ppc64 has some enthusiasm, as it is current in the linux world. That helps us a bit, but not much in this area.


> 
> I don't know if the recenct change also takes gcc's macports-libstdc++
> into account.

Everything about macports-libstdc++ will continue to work exactly as it does now, except they won't get the pre made binaries any more, the libc++ people will.

And tickets against that setup will most likely not get fixed, I would imagine. There are differences in the headers, especially in math and a few other gutty parts, that can be a PITA to work through.

WIth libc++, no such issues, as the builds are identical to all the newer systems, and it's all been worked out already (in most cases …. ).



> 
> I'm not absolutely sure how the change is supposed to be "deployed".
> The functionality to rev-upgrade should be present everywhere, but
> changing the default to libc++ should not be done on 10.5 and earlier.
> 

It _could_ be done in 10.5 Intel, but that makes not much sense. Nobody should be running 10.5 intel anyway, and if we made the libc++ switch in 10.5 intel we'd be endlessly trying to figure out if we're on 10.5 PPC (libstdc++) or 10.5 intel (libc++) and -- ugh. 

So as I see it, the 10.6 cutoff is the right one.

K


More information about the macports-dev mailing list