libcxx @5.0.1_1+universal: upgrade failure on Leopard

[potmj (Michael Pot)]

After successfully building libcxx @5.0.1_0+universal, as part of slowly working through LibcxxOnOlderSystems, further ports now want to upgrade the libcxx dependent.

port -v installed libcxx
The following ports are currently installed:
  libcxx @3.9.1_0-universal platform='darwin 9' archs='i386' date='2017-09-09T16:36:04+1200'
  libcxx @3.9.1_1-universal platform='darwin 9' archs='i386' date='2017-12-28T01:13:04+1300'
  libcxx @5.0.1_0-universal platform='darwin 9' archs='i386' date='2017-12-30T09:05:22+1300'
  libcxx @5.0.1_0+universal (active) platform='darwin 9' archs='i386 ppc x86_64' date='2018-01-09T09:07:46+1300'

It looks like +universal is now inserting whole lot of gcc unsupported options like:-

cc1plus: error: unrecognized command line option "-std=c++11"
cc1plus: error: unrecognized command line option "-stdlib=libc++"

I can't see why @5.0.1_0 worked, & @5.0.1_1 does not. I think I have wound back all the macports.conf changes correctly, so don't see why it is asking for -stdlib=libc++ with Xcode gcc (e.g. have commented out with #cxx_stdlib libc++).

[potmj (Michael Pot)]

Leopard port -v upgrade libcxx

[RJVB (René Bertin)]

Replying to a post from the ticket this discussion was started on:

Replying to potmj:

Replying to RJVB:

Interesting question: is libc++ built with GCC and itself depending on libstdc++ (instead of libc++abi, as on Linux) a viable candidate for the libc++ conversion?

It looks like it is built with gcc (g++4.2).

If GCC 4.2 is new enough to build libc++ 5.0.1 then that would be the easiest way to go, esp. if libc++abi can also be built with that compiler.

I guess the whole idea of bootstrapping is to provide a path to clang from gcc

No, I don't think so, as clang can use libc++ and libstdc++ as the runtime. The need for libc++ stems from the fact that modern C++ variants (starting with C++11) are not implemented by the system libstdc++ version on 10.8 and earlier. Apparently it is not enough just to build a more recent GCC and install its libstdc++ alongside the older system version (as is done on Linux). If that analysis is correct the need for using clang comes from the fact that GCC does not currently have a -stdlib=libc++ option. Hence my (theoretical) interest in the question if a libc++ built like it can be built on Linux would suffice.

I followed the online build-on-Linux instructions and implemented them in a "LinuxPorts" portfile for libc++ (​https://github.com/RJVB/lnxports/blob/master/lang/libcxx/Portfile). This gives me

> ldd /usr/lib/libc++.so.1
        linux-vdso.so.1 =>  (0x00007ffc8a762000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f84aa0c5000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f84a9ea6000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f84a9add000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f84a98c6000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f84a95c0000)
        /lib64/ld-linux-x86-64.so.2 (0x0000556284e61000)

which works just fine when I build applications using clang++ -stdlib=libc++ ... (and according to the benchmarks, it's faster in certain domains). I can link in libraries built with GCC, which suggests that this approach could allow a less invasive libc++ conversion.

[kencu (Ken)]

$ port -v installed libcxx
The following ports are currently installed:
  libcxx @5.0.1_1+universal (active) platform='darwin 9' archs='i386 x86_64' date='2018-01-17T18:04:28-0800'

See recommendation in: 54289#comment:7