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öllert, 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, >> > 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. > > >