On Wed, May 29, 2024 at 10:14 AM Sad Clouds <cryintotheblue...@gmail.com> wrote: > > On Wed, 29 May 2024 09:05:50 +0200 > Richard Biener <richard.guent...@gmail.com> wrote: > > > If you build an executable to pick up libstdc++ via a RUNPATH that apps > > RUNPATH > > should apply to libgcc as well. If you use LD_LIBRARY_PATH the story > > is the same. > > > > So what's your actual failure mode? > > Hello, the concern I have is that GCC binaries themselves > under /opt/gcc-14.1.0 may depend on symbols in libstdc++ and I would > like to have GCC compilers to be self-contained and without any > LD_LIBRARY_PATH hacks. So given: > > $ ldd /opt/gcc-14.1.0/lib/libstdc++.so.6 > /opt/gcc-14.1.0/lib/libstdc++.so.6: > libm.so.5 => /lib/libm.so.5 (0x5486f1dc8000) > libc.so.7 => /lib/libc.so.7 (0x5486f07e5000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x5486f1ff0000) > > So two issues I can think of: > > 1. Some GCC binaries hardcode RUNPATH and use > /opt/gcc-14.1.0/lib/libgcc_s.so.1 while other GCC binaries pick up > /lib/libgcc_s.so.1 instead. Seems somewhat inconsistent and may result > in weird behaviour if there are ABI changes, etc.
GCC binaries link libstdc++ statically. > 2. FreeBSD uses LLVM, but maybe some low-level linker stuff > currently depends on /lib/libgcc_s.so.1? This may change in the future > if LLVM decide to implement their own low-level functions and remove > this dependency completely. > > The RUNPATH is already hard coded for other GCC libraries, so I'm not > sure why this is not done for libstdc++ also. It's likely an artifact of (not) using libtool. It's probably not different for different libraries on purpose. Richard. > Thanks.
