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

[Jonathan Wakely <jwakely.gcc@gmail.com>]

On Tue, 29 Jun 2021 at 17:40, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
>
>
> On Tue, 29 Jun 2021, 17:24 Oleg Smolsky, <osmolsky@netskope.com> wrote:
>>
>>
>>
>> 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.
>
>
> 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.

And if all that shows that you really are using the g++ from GCC 11
and it's finding the libstdc++.so from GCC 11, but still doesn't find
that symbol, then something weird is happening (because that symbol
should be present, and is for everybody else, because otherwise they'd
get testsuite failures complaining about it).