Thank you for the hints, Jonathan! The command is indeed g++, invoked via automake/libtool: /opt/gcc-11/bin/g++ -g -Wall -fno-omit-frame-pointer -gdwarf-4 -O2 -Werror -std=c++17 -Wl,-rpath -Wl,/opt/gcc-11/lib64 -Wl,-rpath -Wl,/opt/3p/lib -o ns_conn_test libs/netsvc/test/ns_conn_test/src/cpp/NsConnTest.o -L/opt/3p/lib ./.libs/libnsevent.a /opt/3p/lib/libzmq.so /opt/gcc-9/lib/../lib64/libstdc++.so /opt/gcc-11/lib/../lib64/libstdc++.so -lpthread -lrt -ldl -lm -lz -Wl,-rpath -Wl,/opt/3p/lib -Wl,-rpath -Wl,/opt/gcc-9/lib/../lib64 -Wl,-rpath -Wl,/opt/gcc-11/lib/../lib64 -Wl,-rpath -Wl,/opt/3p/lib -Wl,-rpath -Wl,/opt/gcc-9/lib/../lib64 -Wl,-rpath -Wl,/opt/gcc-11/lib/../lib64 The problem caused by a wrong libstdc++ version that libtool stamps out. I think it is trying to be smart and discover dependencies from the shared libs (that were compiled a long time ago). Things link when I remove "gcc-9" references - the new executable is linked with the new compiler and uses the new runtime. Thanks again for the prompt and helpful response! Oleg. On Tue, Jun 29, 2021 at 9:40 AM Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: > > > On Tue, 29 Jun 2021, 17:24 Oleg Smolsky, <osmolsky@xxxxxxxxxxxx> wrote: > >> >> >> On Tue, Jun 29, 2021 at 8:42 AM Oleg Smolsky <osmolsky@xxxxxxxxxxxx> >> wrote: >> >>> >>> >>> On Tue, Jun 29, 2021 at 8:39 AM Oleg Smolsky <osmolsky@xxxxxxxxxxxx> >>> wrote: >>> >>>> I am using `g++` to link in both working and failing cases. >>>> >>> >>> The peculiar thing is that the linking issue goes away when I change the >>> reproducer slightly: avoid linking the gcc10-built lib or avoid using >>> std::unordered_map. Either thing is OK by itself... >>> >> >> I've just tried to create a stand-alone test case (with the .so compiled >> separately with a different compiler) but cannot reproduce the issue. >> >> However, I have the following clues from the shared libs: >> >> The GCC10-built lib: >> >> $ objdump -T /opt/3p/lib/libzmq.so | c++filt | grep __throw_ >> 0000000000000000 DF *UND* 0000000000000000 GLIBCXX_3.4 >> std::__throw_bad_alloc() >> 0000000000000000 DF *UND* 0000000000000000 GLIBCXX_3.4 >> std::__throw_length_error(char const*) >> 0000000000000000 DF *UND* 0000000000000000 GLIBCXX_3.4 >> std::__throw_logic_error(char const*) >> 0000000000000000 DF *UND* 0000000000000000 GLIBCXX_3.4.20 >> std::__throw_out_of_range_fmt(char const*, ...) >> >> The GCC11-built lib: >> >> $ objdump -T /opt/3p/lib/libzmq.so-gcc11 | c++filt | grep __throw_ >> 0000000000000000 DF *UND* 0000000000000000 GLIBCXX_3.4 >> std::__throw_bad_alloc() >> 0000000000000000 DF *UND* 0000000000000000 GLIBCXX_3.4 >> std::__throw_length_error(char const*) >> 0000000000000000 DF *UND* 0000000000000000 GLIBCXX_3.4 >> std::__throw_logic_error(char const*) >> 0000000000000000 DF *UND* 0000000000000000 GLIBCXX_3.4.29 >> std::__throw_bad_array_new_length() >> 0000000000000000 DF *UND* 0000000000000000 GLIBCXX_3.4.20 >> std::__throw_out_of_range_fmt(char const*, ...) >> >> Here we can see that `std::__throw_bad_array_new_length()` is only >> present in the new build. >> > > And that symbol is defined in libstdc++.so.6.0.29 so if you link with the > g++ from GCC 11 then it should work. Which tells me that either you're not > linking with g++ (which you already confirmed), or you're using the g++ > from GCC 10, or you have a -L option that causes an older libstdc++.so to > be found before the correct one. > > You should be able to easily verify that for yourself. Run objdump on the > libstdc++.so from GCC 11 and confirm it contains the "missing" symbol. > > Add -v to your link command, to check which GCC executables are being run, > and what linker paths they use. > > Add -Wl,--trace to your linker command to see the names of files as the > linker processes them, to see which libstdc++.so or libstdc++.a is being > found. > > Add -Wl,--trace-symbol=_ZSt28__throw_bad_array_new_lengthv to see all the > input files that contain the missing symbol. > > >
