LibCxx on older systems toolchain blew up on 10.6 -- and fixed -- WAS Re: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?

[Ken Cunningham]

Thanks for the info. I realize it's a small audience, and I'm happy to help, and in fact, don't mind plugging away at it when I have some time. No wonder the OP had trouble though. The toolchain blew up with the last updates to cctools and ld64, and the current instructions and state of things don't appear (to me) to be able to work. 

But I believe have it fixed now, I think, with one small change in the instructions,  and one small change in the ld64 portfile.

I was unable to resuscitate the toolchain after it pulled in ld64 +llvm34, and ultimately I had to uninstall the toolchain completely and start over.

The current LibCxxOnOlderSystems instructions are mixed between +llvm37 and +llvm38. You can't use +llvm37 or clang-3.7 options because they no longer exist in cctools or ld64, so +llvm34 will get pulled back in instead.

The install goes OK if you ignore all the references to +llvm37 or clang-3.7, and just insert +llvm38 or clang-3.8 instead.


HOWEVER you can't build ld64 against +llvm38 due to errors in math.h (as Jeremy pointed out).

sudo port -v upgrade --enforce-variants ld64 -ld64_97 -ld64_127 -ld64_136 -ld64_236


As per:

<http://clang-developers.42468.n3.nabble.com/problems-building-libcxx-td2353619.html>

These math errors appear to be fixed on 10.6 by adding this line in the ld64 portfile -- 

    configure.cppflags-append -I${workpath}/dyld-${dyld_version}/include
+    configure.cppflags-append -U__STRICT_ANSI__

And then it all installs and appears to be a coherent toolchain that works again (with clang-3.8, llvm-3.8).

Best,

Ken



On 2016-08-29, at 1:45 AM, Mojca Miklavec wrote:

> On 28 August 2016 at 23:21, Ken Cunningham wrote:
>> OK - I see what happened.
>> 
>> All traces of llvm37 have been from the new ld64 portfile.
>> 
>> and so when the porfile saw my requested +llvm37, it saw that as no llvm variant, and defaulted to llvm34. And now my toolchain is looking pretty inoperable.
>> 
>> there isn't an llm37 option in the ld64 portfile any longer.
>> 
>> I either have to add one -- or -- reinstall everything
>> 
>> but the <https://trac.macports.org/wiki/LibcxxOnOlderSystems> instructions currently have a mixture of clang-3.7 references and llvm38 references.
> 
> That's partially because it was written when 3.7 made sense (ok, it
> was probably earlier, when 3.5 or 3.6 was there), then 3.8 was
> released, but buggy, so some instructions reverted back to 3.7 ...
> 
>> I thought 3.8 was not yet workable, and so we were to stick with 3.7 -- maybe this is in transition?
> 
> Probably. Your feedback might help though.
> 
>> Looks like I need to let this all settle down in the portfile evolution for a bit, and come back in a few days :>
> 
> Jeremy was cleaning up some of these files recently and it's quite
> likely that not all of the changes were heavily tested on 10.5 and
> 10.6.
> 
> As an example, a recently discovered problem on 10.5 has just been
> fixed and more changes have been applied just now. It makes sense to
> open a new ticket for a problem like the one you mentioned. (Actually,
> it also makes sense to upload crash reports and other problems to a
> ticket in Trac. Trac can easily handle a 2 MB file that pastebin is
> refusing.)
> 
> The setup for libc++ has a very small audience / a very small pool of
> testers. Until we set up new build slaves and attract more users,
> problems are to be expected. (Even then it will still be a problem
> because most developers use the latest OS, so there are very often
> very few people able to help.) Most support for old OSes is there
> because those OSes used to be "up-to-date" some time back and
> developers made sure everything was working (at least until new
> software came up that required C++11). The libc++ support came later
> and is constantly evolving due to releases of newer compilers.
> 
> Mojca