On Tue, 29 Jun 2021, 17:57 Oleg Smolsky, <osmolsky@xxxxxxxxxxxx> wrote: > 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 > Yikes! Yeah, libtool has really created a mess here. > > 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. >> >> >>
