From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) by sourceware.org (Postfix) with ESMTPS id 98A2B3986433 for ; Tue, 30 Aug 2022 17:21:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 98A2B3986433 Received: by mail-ed1-x52d.google.com with SMTP id c59so8906980edf.10 for ; Tue, 30 Aug 2022 10:21:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=JjqsMx2f527igXQiGh1T+xcCsBDNkIRTA5Jkr84UpBg=; b=kuqghuIZuKt00mQlzTqvCXhZC2DGgfl7gL7NH3xiQdXM6UW71cgnLIPQz5AZ0NbNRc fynAYkzBbXYtetT6Q7w442Jb1Gf+DSx4GucpEw9XLZaf99Ow7iMt0yHarcfvAYW+kLNd PWFmE7PnN3COAMPlVuOlECaYyAlBjZ3HXhw2RF+giC3IifQqogNbbBEl3W5IU1z63R9H x4whldEtgxNSkgtBSZJQlVnW5uzIvD1f46rQexY1xwTQIImp26von/ZckeOaEMWUepms Icnd1qWBXbjML410VlB0aMV0YWru5gbhw9mY6X6P1cAdZKRBXApOpZe94OT9PSQ/pBLv E7AA== X-Gm-Message-State: ACgBeo0EFGzdOYJPnFDx4fKLxeHmz0q7QZt25aRhL0DGCbCPiB3ek10U RYmg4C8wNHcqG7TcH8uUWVvd7/GI0KUCY3g7lz+5NYSe X-Google-Smtp-Source: AA6agR5/U21Mrh+y73gwQo3CYZN+PKKRYYuqzL/3eXy9OUC8AZlYxBrvNxL8XaikB4cxhBSgHlPBjjigvqCY9UNIFd0= X-Received: by 2002:a05:6402:524a:b0:43d:aa71:33d8 with SMTP id t10-20020a056402524a00b0043daa7133d8mr21893269edd.33.1661880095466; Tue, 30 Aug 2022 10:21:35 -0700 (PDT) MIME-Version: 1.0 References: <4161b707473552ce74c41c8867c2cc6d77ff4e05.camel@gmail.com> <0951c3b4584404fab95dd7d92af8b6f301b758c7.camel@gmail.com> In-Reply-To: From: Jonathan Wakely Date: Tue, 30 Aug 2022 18:21:22 +0100 Message-ID: Subject: Re: Relation between gcc version and libstdc++ version To: =?UTF-8?Q?Anton_W=C3=B6llert?= Cc: "gcc@gcc.gnu.org" X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2022 17:21:39 -0000 This doesn't belong on this mailing list though, please use the gcc-help list instead. This list is for discussion of GCC development, not help using it. On Tue, 30 Aug 2022, 18:20 Jonathan Wakely, wrote: > > > On Tue, 30 Aug 2022, 17:53 Anton W=C3=B6llert, wro= te: > >> 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=C3=B6llert 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. >> > > > Which is the problem described in the above FAQ. And you should solve it > that way. Apparently you haven't done what it says to do, because you > wouldn't get errors if you had done it. > > See also the page in the manual that the FAQ links to. > > > >> 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++. >> > > Yes, that won't work. > > >> 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? > > > Sometimes the old libstdc++ headers contain invalid C++ which the old GCC > did not diagnose. A newer GCC will give errors when trying to include tho= se > old headers. This is uncommon, but has happened a few times. > > > 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. >> > > > No it doesn't. Using new compilers on older machines works fine. You just > need to do it right. > > > 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. > > > > Clang has various hacks to compile the invalid code in old libstdc++ > headers. This is necessary for compatibility, because clang doesn't contr= ol > which libstdc++ headers are present on a system where clang gets installe= d. > It has to be prepared to cope with arbitrary libstdc++ versions. That's n= ot > an issue for GCC, because libstdc++ is part of GCC, so if you have a give= n > version of GCC, then you have the matching libstdc++ headers and librarie= s, > and you can use them. > > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) by sourceware.org (Postfix) with ESMTPS id 98A2B3986433 for ; Tue, 30 Aug 2022 17:21:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 98A2B3986433 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-x52d.google.com with SMTP id c59so8906980edf.10 for ; Tue, 30 Aug 2022 10:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=JjqsMx2f527igXQiGh1T+xcCsBDNkIRTA5Jkr84UpBg=; b=FCJ0TTl0JkONKmbJ/F8JuA2cDDm75E1kGW65oZJBIzOPrS+EokXkDWdBgNN2y4wjCt qTzQ/fDlGPSS47B/MHma3NrWkyqOuZ8lQH1Cl1CE+S9DMWOWDDVL9tBT2RvvAZZ4fT9b 209FL5T+dDSSE/zeDlSwKSe0g3vha1QSD399ES6iZIXIGjePPfoiQmcw/umwpB5eaYTc REHsvPssbcMIAs2LR2wOQY3qqqEHqfM3cUivf1hlzlQVfsD8HUNx+NVhijFRPsS7G5Qx 23m3fieHsbO28v2bio/lEHL0PQ8gZTgYSEG6Q/RXlbY55kOVFpT4btAfv0YrIOWt9bUP fr0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=JjqsMx2f527igXQiGh1T+xcCsBDNkIRTA5Jkr84UpBg=; b=kuqghuIZuKt00mQlzTqvCXhZC2DGgfl7gL7NH3xiQdXM6UW71cgnLIPQz5AZ0NbNRc fynAYkzBbXYtetT6Q7w442Jb1Gf+DSx4GucpEw9XLZaf99Ow7iMt0yHarcfvAYW+kLNd PWFmE7PnN3COAMPlVuOlECaYyAlBjZ3HXhw2RF+giC3IifQqogNbbBEl3W5IU1z63R9H x4whldEtgxNSkgtBSZJQlVnW5uzIvD1f46rQexY1xwTQIImp26von/ZckeOaEMWUepms Icnd1qWBXbjML410VlB0aMV0YWru5gbhw9mY6X6P1cAdZKRBXApOpZe94OT9PSQ/pBLv E7AA== X-Gm-Message-State: ACgBeo0EFGzdOYJPnFDx4fKLxeHmz0q7QZt25aRhL0DGCbCPiB3ek10U RYmg4C8wNHcqG7TcH8uUWVvd7/GI0KUCY3g7lz+5NYSe X-Google-Smtp-Source: AA6agR5/U21Mrh+y73gwQo3CYZN+PKKRYYuqzL/3eXy9OUC8AZlYxBrvNxL8XaikB4cxhBSgHlPBjjigvqCY9UNIFd0= X-Received: by 2002:a05:6402:524a:b0:43d:aa71:33d8 with SMTP id t10-20020a056402524a00b0043daa7133d8mr21893269edd.33.1661880095466; Tue, 30 Aug 2022 10:21:35 -0700 (PDT) MIME-Version: 1.0 References: <4161b707473552ce74c41c8867c2cc6d77ff4e05.camel@gmail.com> <0951c3b4584404fab95dd7d92af8b6f301b758c7.camel@gmail.com> In-Reply-To: From: Jonathan Wakely Date: Tue, 30 Aug 2022 18:21:22 +0100 Message-ID: Subject: Re: Relation between gcc version and libstdc++ version To: =?UTF-8?Q?Anton_W=C3=B6llert?= Cc: "gcc@gcc.gnu.org" Content-Type: multipart/alternative; boundary="000000000000bfe99a05e7789ce6" X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,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: Message-ID: <20220830172122.UPscmhuxsf-CMVejTKWCOSjkQYs8jdwK61ZbjIBry0E@z> --000000000000bfe99a05e7789ce6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This doesn't belong on this mailing list though, please use the gcc-help list instead. This list is for discussion of GCC development, not help using it. On Tue, 30 Aug 2022, 18:20 Jonathan Wakely, wrote: > > > On Tue, 30 Aug 2022, 17:53 Anton W=C3=B6llert, wro= te: > >> 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=C3=B6llert 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. >> > > > Which is the problem described in the above FAQ. And you should solve it > that way. Apparently you haven't done what it says to do, because you > wouldn't get errors if you had done it. > > See also the page in the manual that the FAQ links to. > > > >> 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++. >> > > Yes, that won't work. > > >> 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? > > > Sometimes the old libstdc++ headers contain invalid C++ which the old GCC > did not diagnose. A newer GCC will give errors when trying to include tho= se > old headers. This is uncommon, but has happened a few times. > > > 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. >> > > > No it doesn't. Using new compilers on older machines works fine. You just > need to do it right. > > > 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. > > > > Clang has various hacks to compile the invalid code in old libstdc++ > headers. This is necessary for compatibility, because clang doesn't contr= ol > which libstdc++ headers are present on a system where clang gets installe= d. > It has to be prepared to cope with arbitrary libstdc++ versions. That's n= ot > an issue for GCC, because libstdc++ is part of GCC, so if you have a given > version of GCC, then you have the matching libstdc++ headers and librarie= s, > and you can use them. > > > --000000000000bfe99a05e7789ce6--