Relation between gcc version and libstdc++ version
Hello list! I was trying to build a cross-compilation toolchain for a specific target using a newer GCC version, than the one that the binaries were build on the target. The C part seems to work well, but the C++ part doesn't. It seems that the G++ ships it's own libstdc++ include headers. 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). 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? If not, is there any reason this is hard-coded? With clang it looks like you can specify "any" libstdc++ version you want, although I haven't tested it yet. Kind regards, Anton
Re: Relation between gcc version and libstdc++ version
On Tue, 30 Aug 2022, 15:48 Anton Wöllert via Gcc, wrote: > Hello list! > > I was trying to build a cross-compilation toolchain for a specific > target using a newer GCC version, than the one that the binaries were > build on the target. > > The C part seems to work well, but the C++ part doesn't. It seems that > the G++ ships it's own libstdc++ include headers. Yes, because libstdc++ is part of GCC. 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 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. 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.
Re: Relation between gcc version and libstdc++ version
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
Re: Relation between gcc version and libstdc++ version
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.
Re: Relation between gcc version and libstdc++ version
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. > > >
Re: Relation between gcc version and libstdc++ version
Thanks for your comments, sorry for posting on the wrong mailing list. I'll just restate my initial question here on gcc-help again: I was trying to build a cross-compilation toolchain for a specific target using a newer GCC version, than the one that the binaries were build on the target. The C part seems to work well, but the C++ part doesn't. It seems that the G++ ships it's own libstdc++ include headers. 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). 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? If not, is there any reason this is hard-coded? With clang it looks like you can specify "any" libstdc++ version you want, although I haven't tested it yet. On Tue, 2022-08-30 at 18:21 +0100, Jonathan Wakely wrote: > 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. > > > > > 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. > > So what is the right way to compile software with a newer version of gcc for a target, that has an older version of gcc? I can't find any hints about that in documentation. Should I ship the newer libstdc++.so with the application to the target and set LD_LIBRARY_PATH? Then I probably also have to add other libraries, right? Kind regards, Anton
Proposing Sourceware as SFC member project
Hi! If you have an interest in the long term future of the sourceware hosting server which this project is using, please consider checking out this thread on our local overseers@ mailing list. Everything is fine, we're just thinking ahead. https://sourceware.org/pipermail/overseers/2022q3/018802.html Chris Faylor Frank Eigler Mark Wielaard
Re: Relation between gcc version and libstdc++ version
On Tue, 30 Aug 2022, 19:46 Anton Wöllert, wrote: > Thanks for your comments, > > sorry for posting on the wrong mailing list. I'll just restate my > initial question here on gcc-help again: > >I was trying to build a cross-compilation toolchain for a specific >target using a newer GCC version, than the one that the binaries >were build on the target. > >The C part seems to work well, but the C++ part doesn't. It seems >that the G++ ships it's own libstdc++ include headers. 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). 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? >If not, is there any reason this is hard-coded? > >With clang it looks like you can specify "any" libstdc++ version you >want, although I haven't tested it yet. > > On Tue, 2022-08-30 at 18:21 +0100, Jonathan Wakely wrote: > > 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. > > > > > > > > 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. > > > > > So what is the right way to compile software with a newer version of > gcc for a target, that has an older version of gcc? I can't find any > hints about that in documentation. Should I ship the newer > libstdc++.so with the application to the target and set > LD_LIBRARY_PATH? As the documentation says, there are other ways that might be better than LD_LIBRARY_PATH, but they all require shipping the new libstdc++.so.6 with the application. Static linking is another option, which avoids needing the new libstdc++.so.6 at runtime. Then I probably also have to add other libraries, > right? > No, you shouldn't need to. > > Kind regards, > Anton > > >
Usage of the C++ stdlib unordered_map in GCC
Hello, I was preparing a patch for GCC and used the unordered_map from the C++ stdlib in my patch. Later on, I noticed that it is used nowhere else inside GCC except for some files in the go frontend. I wondered, now that building GCC requires a C++11 host compiler, whether there is a consensus on which data structure implementation is preferred. Should I rather use a hash_map instead of an unordered_map or is it on my side to decide which one I choose? - Tim
Re: Usage of the C++ stdlib unordered_map in GCC
On Tue, Aug 30, 2022 at 09:57:45PM +0200, Tim Lange wrote: > Hello, > > I was preparing a patch for GCC and used the unordered_map from the C++ > stdlib in my patch. Later on, I noticed that it is used nowhere else inside > GCC except for some files in the go frontend. > > I wondered, now that building GCC requires a C++11 host compiler, whether > there is a consensus on which data structure implementation is preferred. > Should I rather use a hash_map instead of an unordered_map or is it on my > side to decide which one I choose? I think you're probably better off using a hash_map; std::unordered_map has efficiency issues as described in https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2028r0.pdf Marek
