[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