* Jakub Jelinek: > On Wed, Dec 31, 2025 at 01:09:24PM +0000, Prathamesh Kulkarni wrote: >> >From what I see, the issue with pseudo dependency on libatomic.so >> >(DT_NEEDED) probably comes from libatomic.so >> being placed in gcc subdir, which is where toplevel libtool.m4 seems to pick >> it up from: > > Guess the important question is, does libtool screw this up only for > libstdc++.so.6 or for tons of other libraries. > for i in `find -name lib\*.so.\*.\*.\*[0-9]`; do readelf -Wd $i | grep -q > NEEDED.*libatomic && echo $i; done > ./libsanitizer/ubsan/.libs/libubsan.so.1.0.0 > ./libsanitizer/asan/.libs/libasan.so.8.0.0 > ./libsanitizer/hwasan/.libs/libhwasan.so.0.0.0 > ./libsanitizer/lsan/.libs/liblsan.so.0.0.0 > ./libsanitizer/tsan/.libs/libtsan.so.2.0.0 > ./32/libsanitizer/ubsan/.libs/libubsan.so.1.0.0 > ./32/libsanitizer/asan/.libs/libasan.so.8.0.0 > ./32/libstdc++-v3/src/.libs/libstdc++.so.6.0.35 > ./libgcobol/.libs/libgcobol.so.2.0.0 > ./libstdc++-v3/src/.libs/libstdc++.so.6.0.35 > suggests that it isn't a problem just for libstdc++ but for the > sanitizers/libgcobol at least as well (looking at gcc 15, the same command > prints nothing). So, it would be nice to fix this in libtool upstream > and backport to the gcc libtool copy.
One way to work around the libtool problem would be to stick the as-needed into an existing .so linker script, or create a new one under a different name (say libatomic_optional.so) that has AS_NEEDED in it, and link with -latomic_optional. Then libtool would not have to be taught about --push-state/--pop-state etc. Thanks, Florian
