public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely.gcc@gmail.com>
To: "Anton Wöllert" <a.woellert@gmail.com>
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: Relation between gcc version and libstdc++ version
Date: Tue, 30 Aug 2022 18:20:43 +0100	[thread overview]
Message-ID: <CAH6eHdR25-3i1oe2xOGqzBKtY2QvTrdgafEaRdGtOGnNt8Nb2Q@mail.gmail.com> (raw)
In-Reply-To: <0951c3b4584404fab95dd7d92af8b6f301b758c7.camel@gmail.com>

On Tue, 30 Aug 2022, 17:53 Anton Wöllert, <a.woellert@gmail.com> wrote:

> 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, <gcc@gcc.gnu.org>
> > 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 those
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 control
which libstdc++ headers are present on a system where clang gets installed.
It has to be prepared to cope with arbitrary libstdc++ versions. That's not
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 libraries,
and you can use them.

WARNING: multiple messages have this Message-ID
From: Jonathan Wakely <jwakely.gcc@gmail.com>
To: "Anton Wöllert" <a.woellert@gmail.com>
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: Relation between gcc version and libstdc++ version
Date: Tue, 30 Aug 2022 18:20:43 +0100	[thread overview]
Message-ID: <CAH6eHdR25-3i1oe2xOGqzBKtY2QvTrdgafEaRdGtOGnNt8Nb2Q@mail.gmail.com> (raw)
Message-ID: <20220830172043.isLrOFj_utJNEJO9gtJNk5r8GqIInmd9TMXazWJ_EBw@z> (raw)
In-Reply-To: <0951c3b4584404fab95dd7d92af8b6f301b758c7.camel@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3483 bytes --]

On Tue, 30 Aug 2022, 17:53 Anton Wöllert, <a.woellert@gmail.com> wrote:

> 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, <gcc@gcc.gnu.org>
> > 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 those
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 control
which libstdc++ headers are present on a system where clang gets installed.
It has to be prepared to cope with arbitrary libstdc++ versions. That's not
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 libraries,
and you can use them.

  reply	other threads:[~2022-08-30 17:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-30 14:47 Anton Wöllert
2022-08-30 16:09 ` Jonathan Wakely
2022-08-30 16:09   ` Jonathan Wakely
2022-08-30 16:53   ` Anton Wöllert
2022-08-30 17:20     ` Jonathan Wakely [this message]
2022-08-30 17:20       ` Jonathan Wakely
2022-08-30 17:21       ` Jonathan Wakely
2022-08-30 17:21         ` Jonathan Wakely
2022-08-30 18:46         ` Anton Wöllert
2022-08-30 19:24           ` Jonathan Wakely
2022-08-30 19:24             ` Jonathan Wakely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAH6eHdR25-3i1oe2xOGqzBKtY2QvTrdgafEaRdGtOGnNt8Nb2Q@mail.gmail.com \
    --to=jwakely.gcc@gmail.com \
    --cc=a.woellert@gmail.com \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).