From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jwakely.gcc@gmail.com>
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com
 [IPv6:2a00:1450:4864:20::42b])
 by sourceware.org (Postfix) with ESMTPS id E60253858C27
 for <gcc-help@gcc.gnu.org>; Tue, 29 Jun 2021 16:40:51 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E60253858C27
Received: by mail-wr1-x42b.google.com with SMTP id i8so46560wrc.0
 for <gcc-help@gcc.gnu.org>; Tue, 29 Jun 2021 09:40:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=T+yYQaQ94efr1GQVYtZ5IaN/CXQIfgdiArq2QaCVpU8=;
 b=Tm7rJw3JEn4A8tKLigl4y8goy3sEfpIGDHzxffO+et6uMPPw3u+CDBrEcByg0UD4yt
 6UkYapER0bmBf3pHnaOxlXoE096weHz8SMER6ySxi7A3S+m/xoKfANT3kEbtcP9fTyjv
 07UmcyjZuUphxX/HfRU4g6r3iISPrzsmqXkCaON3Q9XuiAIVtJ7jBQwQZocBUJBodjyw
 KYoIE7t+8lLo3zW2eXgYOk1nJZVs2ONZyYDl92vxanlAloLdQ/T2DzkTJlDU7ge+mIeP
 uuwW/vH7YpYcdfUSgDKoAHtmvjsebsjJe89cAKpRhP22WOPP7W5AuU9VpqfTV5vKx+Gx
 hb8Q==
X-Gm-Message-State: AOAM5326FAaiO0Xb2k5TN2USfmFfCqlAJPgW1Lhg/i343p50S8rYeEoq
 3iWik8e/LfmSIFUuHI6cmz6lMnKcT8356EpqK7w=
X-Google-Smtp-Source: ABdhPJyGIdqLpMXMmJki/R1k48g2iEZ0TF9dmTtzmpQjHn+VljDOaw4rUGKqsABl4t/kbDeFDoG1FB4LmctsEo6WWtQ=
X-Received: by 2002:a5d:6846:: with SMTP id o6mr33504574wrw.89.1624984851100; 
 Tue, 29 Jun 2021 09:40:51 -0700 (PDT)
MIME-Version: 1.0
References: <CAAucFJcVvwVedKBxjGcM+2uZsdZ6UoA8KCyX+Qa1qJctJUcbFA@mail.gmail.com>
 <CAH6eHdRUF+jfaJa1QU8aentWfk_rU1tZDxo=RRh+ixkNfXk0Mg@mail.gmail.com>
 <CAAucFJck7_=mvvt4ekQ9RuHT6XB++CHtxDDgK=7q5jB3SFrnwQ@mail.gmail.com>
 <CAAucFJe1u7TH7rgQ4=kp=kP-MaSm_c+MDpUnOydA5t_B7jxv7g@mail.gmail.com>
 <CAAucFJemxBbSNBhj+D0DEPo7YOLz3tQLRO80+eBrumNr6bYeEw@mail.gmail.com>
In-Reply-To: <CAAucFJemxBbSNBhj+D0DEPo7YOLz3tQLRO80+eBrumNr6bYeEw@mail.gmail.com>
From: Jonathan Wakely <jwakely.gcc@gmail.com>
Date: Tue, 29 Jun 2021 17:40:40 +0100
Message-ID: <CAH6eHdRZ3Kj-fyPnGEjWhALSqNz44wCAxnm4AHeuhGpjycuEQg@mail.gmail.com>
Subject: Re: [EXTERNAL] Re: Linking issue when mixing GCC10/GCC11 artifacts
To: Oleg Smolsky <osmolsky@netskope.com>
Cc: gcc-help <gcc-help@gcc.gnu.org>
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE,
 RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS,
 TXREP autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
Content-Type: text/plain; charset="UTF-8"
X-Content-Filtered-By: Mailman/MimeDel 2.1.29
X-BeenThere: gcc-help@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-help mailing list <gcc-help.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-help>,
 <mailto:gcc-help-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-help/>
List-Post: <mailto:gcc-help@gcc.gnu.org>
List-Help: <mailto:gcc-help-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-help>,
 <mailto:gcc-help-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jun 2021 16:40:54 -0000

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.