[EXTERNAL] Re: Linking issue when mixing GCC10/GCC11 artifacts

Oleg Smolsky osmolsky@netskope.com
Tue Jun 29 16:24:47 GMT 2021


On Tue, Jun 29, 2021 at 8:42 AM Oleg Smolsky <osmolsky@netskope.com> wrote:

>
>
> On Tue, Jun 29, 2021 at 8:39 AM Oleg Smolsky <osmolsky@netskope.com>
> 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.


More information about the Gcc-help mailing list