From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by sourceware.org (Postfix) with ESMTPS id D002D385841A for ; Tue, 30 Aug 2022 16:53:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D002D385841A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x52f.google.com with SMTP id z8so6221512edb.6 for ; Tue, 30 Aug 2022 09:53:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc; bh=eBqJMDGUD59RPFppZcf2S2ZFa9Qnbcgaaf1fdCjZ0H8=; b=BiSZYza+1tyGBqjvfuwBt6PrgWHgDC3fDi8DfrUZCO0Wsnk9PeIyxqT1lELu81YNKe WOzsG/jReVIYxIcjzIbMI8dkR36a/8e71tP9CGSMzkNtisk+YabUBGLi+7Vx81tgdkpx DL/OycMZeHwA9+NS6dAPh1xsWP4v32x/yUuSY9e917H1Bk4PQwkR/7LjjhQa5OgaZE8P iO5lfxKJb9V5ypRq4xH+eAWlBTj/Y4tfM1mk+dzT5pfCyEgPHZgipKJ+or9SpkRpAh2/ ka/nUic1GBx3LSMUnTaDS1PtNfj6O9e+mGAbik5KrrXynzcMoLyD3F/RkWAAQGdYDbaN inGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc; bh=eBqJMDGUD59RPFppZcf2S2ZFa9Qnbcgaaf1fdCjZ0H8=; b=Q4to0ONo9ePRnUltNzu/PTGVE+opC2fXxpLicrB6WLu+5HV4ISCN32JBiZE4uTgwmq hvL3NeRRkbXRjTtQfC9gHzzC6VlYWBO5h9WVOYnPasuEKojG8f62doAOTdppjMxUc+k1 8oWM3e2ROkrwrL+4LBmgAh90azIyianxfx9A0YbyLmma55Ea6YFB51CxCtGQmKb/fHTY HzC1bD07FhlBl1H0mtvkv9W6TquHZdecrdFNKSWn4VGqt2E/3xtlxdamo4uYNrEV3uIx WsJsPASQonkIXr09AgOI1fxWsUnVYJNQpYa65ukbWCEIFg9TENYRrICkvfiB+Oz/KUK1 TZKQ== X-Gm-Message-State: ACgBeo2t+VbHWDFbedxHfG8Fa1FoWX6fhq8se+dQZPCIWh3GIOa3wWUL CebYyBkTkUppxZghNyJEnkw= X-Google-Smtp-Source: AA6agR7TIuzCQA+nWu0Q4T3XWv0WRAXk5rU/qU6uIYWS7JBOLiizKyOlgVEkVCN+KhjdBR5mdGIYqQ== X-Received: by 2002:a05:6402:d0b:b0:443:df38:9df with SMTP id eb11-20020a0564020d0b00b00443df3809dfmr20739606edb.9.1661878399296; Tue, 30 Aug 2022 09:53:19 -0700 (PDT) Received: from [192.168.0.152] (ip1f10f159.dynamic.kabel-deutschland.de. [31.16.241.89]) by smtp.gmail.com with ESMTPSA id p17-20020a056402501100b004481af6c760sm5963345eda.0.2022.08.30.09.53.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Aug 2022 09:53:18 -0700 (PDT) Message-ID: <0951c3b4584404fab95dd7d92af8b6f301b758c7.camel@gmail.com> Subject: Re: Relation between gcc version and libstdc++ version From: Anton =?ISO-8859-1?Q?W=F6llert?= To: Jonathan Wakely Cc: "gcc@gcc.gnu.org" Date: Tue, 30 Aug 2022 18:53:17 +0200 In-Reply-To: References: <4161b707473552ce74c41c8867c2cc6d77ff4e05.camel@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Jonathan, thank you for your reply! On Tue, 2022-08-30 at 17:09 +0100, Jonathan Wakely wrote: > > > On Tue, 30 Aug 2022, 15:48 Anton Wöllert via Gcc, > wrote: > > If this libstdc++ is > > newer than the one one the target, I get undefined references > > (because > > there are some newer implementation details and things like that). > > Then you're not telling the executable how find the new libstdc++. > > https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths > > I tried to do that. If I let the toolchain use it's own libstdc++.so, then I get at runtime unresolved symbols due to the version mismatch (these GLIBCXX errors). This is clear. If I force the toolchain to link against the older target libstdc++, then I get undefined symbols at compile time, because it is still using it's own shipped headers for the newer libstdc++, which have implementation details that use newer "functions/symbols" that are not available in the old libstdc++. If I furthermore remove the shipped headers and force it to include the c++ headers from the older libstdc++, then everything works out. But this whole "patching" seems very hacky. > > Is > > it possible to tell G++/GCC to use the libstdc++.so from the target > > and > > also to use the C++ headers (like iostream) from the target? > > It's possible, but unsupported and probably won't work. So it seems to be indeed possible, but not intended. > > > If not, is there any reason this is hard-coded? > > The libstdc++ headers are tightly coupled to the GCC version, so > headers from a given GCC release might not even compile with a newer > or older GCC. I would see an argument if you're trying to compile an newer libstdc++ with an older gcc - but why not the other way around? C++ in general tries to be very good in backward compatibility. This essentially means that you can't use newer compilers with more features/bugfixes to compile software for older targets. Is there any obvious reason this is not supported? Clang, for example, also seems to be able to compile/link against different libstdc++ versions. I'm just wondering. Best, Anton