Re: libstdc++ and missing RUNPATH
On Wed, May 29, 2024 at 8:47 AM Sad Clouds via Gcc wrote: > > Hello, I'm noticing some issues with libstdc++ after building GCC from > sources and installing into /opt/gcc-14.1.0. Specifically: > > $ objdump -x /opt/gcc-14.1.0/lib/libstdc++.so.6 | grep RUNPATH > > $ 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 (0x5486f1ff) > > As you can see libstdc++ depends on libgcc_s but libstdc++ is missing > RUNPATH, so it picks up whatever is found in /lib rather than in target > install directory /opt/gcc-14.1.0 > > Contrast this with: > > $ objdump -x /opt/gcc-14.1.0/lib/libcc1.so.0 | grep RUNPATH > RUNPATH /opt/gcc-14.1.0/lib > > $ ldd /opt/gcc-14.1.0/lib/libcc1.so.0 > /opt/gcc-14.1.0/lib/libcc1.so.0: > libstdc++.so.6 => /opt/gcc-14.1.0/lib/libstdc++.so.6 (0x59c32880) > libm.so.5 => /lib/libm.so.5 (0x59c325081000) > libc.so.7 => /lib/libc.so.7 (0x59c3245c4000) > libgcc_s.so.1 => /opt/gcc-14.1.0/lib/libgcc_s.so.1 (0x59c326ac) > > Is it intentional or is it a bug? What is the best way to add RUNPATH > to libstd++? Do I modify CFLAGS_FOR_TARGET or LDFLAGS_FOR_TARGET? 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? > PS. GCC was configured with these options: > > $ /opt/gcc-14.1.0/bin/gcc -v > Using built-in specs. > COLLECT_GCC=/opt/gcc-14.1.0/bin/gcc > COLLECT_LTO_WRAPPER=/opt/gcc-14.1.0/libexec/gcc/aarch64-unknown-freebsd14.0/14.1.0/lto-wrapper > Target: aarch64-unknown-freebsd14.0 > Configured with: ../../src/gcc-14.1.0/configure --prefix=/opt/gcc-14.1.0 > --build=aarch64-unknown-freebsd14.0 --host=aarch64-unknown-freebsd14.0 > --target=aarch64-unknown-freebsd14.0 --enable-languages=c,c++,ada > --enable-shared --enable-threads=posix --enable-bootstrap --disable-multilib > --disable-nls --with-as=/opt/gcc-14.1.0/bin/as > --with-ld=/opt/gcc-14.1.0/bin/ld > Thread model: posix > Supported LTO compression algorithms: zlib > gcc version 14.1.0 (GCC)
Re: libstdc++ and missing RUNPATH
On Wed, 29 May 2024 09:05:50 +0200 Richard Biener 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 (0x5486f1ff) 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.
Re: libstdc++ and missing RUNPATH
On Wed, May 29, 2024 at 10:14 AM Sad Clouds wrote: > > On Wed, 29 May 2024 09:05:50 +0200 > Richard Biener 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 (0x5486f1ff) > > 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.
Re: libstdc++ and missing RUNPATH
On Wed, 29 May 2024 at 09:15, Sad Clouds via Gcc wrote: > > On Wed, 29 May 2024 09:05:50 +0200 > Richard Biener 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 (0x5486f1ff) > > 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.
Re: libstdc++ and missing RUNPATH
On Wed, 29 May 2024 10:33:16 +0100
Jonathan Wakely wrote:
> > 1. Some GCC binaries hardcode RUNPATH and use
>
> Binaries, or just libraries?
>
I meant GCC shared library binaries. The actual executables under bin/
do not use RUNPATH with GCC default build behaviour.
I think FreeBSD GCC compiler from ports was patched to automatically
insert RUNPATH into all binaries:
$ cat test.c
int main(void){}
$ /usr/local/gnat13/bin/gcc test.c
$ objdump -x a.out | grep RUNPATH
RUNPATH /usr/local/gnat13/lib
So when I use it as a bootstrap Ada compiler, my new compiler has
"RUNPATH /usr/local/gnat13/lib" sprinkled all over its binaries. I can
fix this by building my own compiler from sources multiple times,
however it is FreeBSD specific issue and not related to my original
libstdc++ RUNPATH question.
> > /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?
No I haven't seen any failures yet. If GCC is using libstdc++
statically, then I guess this is not an issue. I just want to make sure
GCC compiler itself does not have any broken/fragile shared library
dependencies.
Thanks.
Re: configure adds -std=gnu++11 to CXX variable
> "Jason" == Jason Merrill writes: Jason> Thanks, though I don't think all that code needs to go; Jason> AC_PROG_CXX_STDCXX_EDITION_TRY still looks useful for a project that Jason> relies on features from a particular standard. We just don't want Jason> AC_PROG_CXX to invoke it. I didn't read the macro but there's also config/ax_cxx_compile_stdcxx.m4. gdb uses this to make sure C++17 is available. Tom
Re: configure adds -std=gnu++11 to CXX variable
On Wed, May 29, 2024 at 1:34 PM Tom Tromey wrote: > > "Jason" == Jason Merrill writes: > > Jason> Thanks, though I don't think all that code needs to go; > Jason> AC_PROG_CXX_STDCXX_EDITION_TRY still looks useful for a project that > Jason> relies on features from a particular standard. We just don't want > Jason> AC_PROG_CXX to invoke it. > > I didn't read the macro but there's also config/ax_cxx_compile_stdcxx.m4. > gdb uses this to make sure C++17 is available. Good point, that's what GCC uses as well. Jason
Re: Archaeology time: Help me identify these ancient OSes and vendors
On 28 May 2024, at 14:35, Zack Weinberg wrote: > These are probably all either vendor or OS names from the late 1980s or > early 1990s. Can anyone help me fill out the following list of things > that ought to appear in testsuite/config-sub.data, if I knew what to > put in place of the question marks? > > ???-storm-chaos ???-???-??? I remember the storm-chaos port being added to binutils and/or GCC in around 2000 -- the name was fairly distinctive! A bit of spelunking leads to https://sourceware.org/pipermail/binutils/2000-November/007871.html https://sourceware.org/pipermail/binutils/2000-November/007873.html and thence to https://github.com/chaos4ever/chaos John
gcc-11-20240529 is now available
Snapshot gcc-11-20240529 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20240529/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision a3168fd048f6a40e5c7869205b754e16997882a4 You'll find: gcc-11-20240529.tar.xz Complete GCC SHA256=bb9487ae72acce7b050fd1917206bb276baa582b4378f15326c06c63e4747955 SHA1=223704624481f2ea2b46aec8e7093ffbb437e875 Diffs from 11-20240522 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Is fcommon related with performance optimization logic?
Dear Sir/Madam, We found that running on intel SPR UnixBench compiled with gcc 10.3 performs worse than with gcc 8.5 for dhry2reg benchmark. I found it related with -fcommon option which is disabled in 10.3 by default. Fcommon will make global variables addresses in special order in bss section(watching by nm -n) whatever they are defined in source code. We are wondering if fcommon has some special performance optimization process? (I also post the subject to gcc-help. Hope to get some suggestion in this mail list. Sorry for bothering.) Best regards. Clark Zhao
Re: Is fcommon related with performance optimization logic?
On Wed, May 29, 2024 at 7:13 PM 赵海峰 via Gcc wrote: > > Dear Sir/Madam, > > > We found that running on intel SPR UnixBench compiled with gcc 10.3 performs > worse than with gcc 8.5 for dhry2reg benchmark. > > > I found it related with -fcommon option which is disabled in 10.3 by default. > Fcommon will make global variables addresses in special order in bss > section(watching by nm -n) whatever they are defined in source code. > > > We are wondering if fcommon has some special performance optimization process? > > > (I also post the subject to gcc-help. Hope to get some suggestion in this > mail list. Sorry for bothering.) This was already filed as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114532 . But someone needs to go in and do more analysis of what is going wrong. The biggest difference for x86_64 is how the variables are laid out and by who (the compiler or the linker). There is some notion that -fno-common increases the number of L1-dcache-load-misses and that points to the layout of the variable differences causing the difference. But nobody has gone and seen which variables are laid out differently and why. I am suspecting that small changes in the code/variables would cause layout differences which will cause the cache misses which can cause the performance which is almost all by accident. I suspect adding -fdata-sections will cause another performance difference here too. And there is not much GCC can do about this since data layout is "hard" to do to get the best performance always. Thanks, Andrew Pinski > > > Best regards. > > > Clark Zhao
