[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