[MacPorts] #55709: libcxx @5.0.1_1+universal: upgrade failure on Leopard

MacPorts noreply at macports.org
Wed Jan 17 22:45:38 UTC 2018


#55709: libcxx @5.0.1_1+universal:  upgrade failure on Leopard
---------------------+-------------------------------
  Reporter:  potmj   |      Owner:
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:  2.4.2
Resolution:          |   Keywords:  leopard universal
      Port:  libcxx  |
---------------------+-------------------------------

Comment (by RJVB):

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

 Replying to [comment:11 potmj]:
 > Replying to [comment:8 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.

--
Ticket URL: <https://trac.macports.org/ticket/55709#comment:1>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list