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.
