On Wed, 29 May 2024 at 09:15, Sad Clouds via Gcc <gcc@gcc.gnu.org> 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
Binaries, or just libraries? > /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. Have you observed an actual failure? > 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. The sanitizer libraries use a RUNPATH, I don't know why. That doesn't imply that libstdc++ should do so too. GCC documents that it doesn't use RPATH/RUNPATH: https://gcc.gnu.org/faq.html#rpath https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dynamic_or_shared.html#manual.intro.using.linkage.dynamic > > Thanks.
