On Wed, 29 May 2024 09:05:50 +0200
Richard Biener <[email protected]> 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.
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.
Thanks.
