[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 Arsen Arsenović changed: What|Removed |Added CC||arsen at gcc dot gnu.org --- Comment #45 from Arsen Arsenović --- to recap what I've found in the bug that just got marked as a dupe: this is set through a chain of all-target-libstdc++-v3 -> RAW_CXX_TARGET_EXPORTS -> BASE_TARGET_EXPORTS the idea here is that newly-built target code should use existing target libraries rather than $build libraries (which makes sense). however, the existing approach makes *all* code involved in building target libs use newly-built libraries, which results in libstdc++ et al being *downgraded* for make, sh, msgfmt, ld, ... (but not gcc, since the new gcc is used). a fix for this might be to build target libraries with adjusted rpaths, or something similar, but I'm not sure of the full scope of the issue yet (my debugging this morning was cursory), so I'm not sure if that's sufficient. I'm also not sure how to deal with static linking - maybe libtool helps?
[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 Arsen Arsenović changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #44 from Arsen Arsenović --- *** Bug 109602 has been marked as a duplicate of this bug. ***
[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #43 from Jonathan Wakely --- I still haven't figured out why configure is setting LD_LIBRARY_PATH when using ld.gold. It's not coming from the libstdc++ build, I think it's the top-level configure which is setting RPATH_ENVVAR.
[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #42 from Artem S. Tashkinov --- (In reply to Jonathan Wakely from comment #41) > (In reply to Artem S. Tashkinov from comment #31) > > And one final tidbit, `make LD=ld.bfd install prefix=/tmp/GCC-11.3` fails: > > Is this supposed to work? > > Why aren't you using DESTDIR? I've checked Fedora's spec file and they do `make install prefix`, so that's what I tried. I've never figured out why some projects use DESTDIR and others prefix.
[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #41 from Jonathan Wakely --- (In reply to Artem S. Tashkinov from comment #31) > And one final tidbit, `make LD=ld.bfd install prefix=/tmp/GCC-11.3` fails: Is this supposed to work? Why aren't you using DESTDIR?
[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #40 from Artem S. Tashkinov --- (In reply to Vincent Lefèvre from comment #39) > (In reply to Jonathan Wakely from comment #38) > > (In reply to Vincent Lefèvre from comment #35) > > > (I reported it in 2012, with Jonathan Nieder's patch to fix it, but after > > > 10 > > > years, there is still no reaction from the developers!) > > > > So don't use gold then. > > It is (was) installed by default on some machines. And users don't > necessarily know that it is the cause of failures when building other > software (like this GCC bug). Yes, it was installed by default for me - I've never changed it manually. Checking for available linkers (ld.bfd, ld.gold - at least here on Fedora) and choosing the right one sounds trivial, so I guess someone could write a patch. Should I open a new bug report about comment #31 or it's a known issue?
[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #39 from Vincent Lefèvre --- (In reply to Jonathan Wakely from comment #38) > (In reply to Vincent Lefèvre from comment #35) > > (I reported it in 2012, with Jonathan Nieder's patch to fix it, but after 10 > > years, there is still no reaction from the developers!) > > So don't use gold then. It is (was) installed by default on some machines. And users don't necessarily know that it is the cause of failures when building other software (like this GCC bug).
[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #38 from Jonathan Wakely --- (In reply to Vincent Lefèvre from comment #35) > (I reported it in 2012, with Jonathan Nieder's patch to fix it, but after 10 > years, there is still no reaction from the developers!) So don't use gold then.
[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #37 from Andrew Pinski --- (In reply to Vincent Lefèvre from comment #36) > An alternative solution: for programs that are known to potentially fail due > to built libraries and LD_LIBRARY_PATH, GCC could define wrappers that clean > up LD_LIBRARY_PATH before executing the real program. That should not be too hard to do as GCC already does that while building for as and sometimes ld, see gcc/exec-tool.in. It is mostly for while building binutils and GCC together (which is supported still).
[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #36 from Vincent Lefèvre --- An alternative solution: for programs that are known to potentially fail due to built libraries and LD_LIBRARY_PATH, GCC could define wrappers that clean up LD_LIBRARY_PATH before executing the real program.
[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #35 from Vincent Lefèvre --- And since the title of this bug was changed to mention that this is related to the GNU gold linker, there is a runpath bug in this linker that might affect libtool (perhaps causing it to use LD_LIBRARY_PATH?): https://sourceware.org/bugzilla/show_bug.cgi?id=13764 (I reported it in 2012, with Jonathan Nieder's patch to fix it, but after 10 years, there is still no reaction from the developers!) So you may want to try this patch to see if this solves the issue.
[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #34 from Andrew Pinski --- (In reply to Vincent Lefèvre from comment #33) > (In reply to Andrew Pinski from comment #32) > > The runpath won't work because the libraries are installed yet. > > This is what libtool does for GNU MPFR, and this works fine. For instance, > when building test programs, I can see: > > -Wl,-rpath -Wl,/home/vinc17/software/mpfr/src/.libs > > so that it doesn't need to change LD_LIBRARY_PATH. (The test programs don't > need to be installed, so that using the path to the build directory will not > yield any issue, but AFAIK, if need be, libtool supports relinking of > programs to be installed.) Relinking is a no go really for GCC as far as I know. Especially when you might build as one user and install as another (root); relinking causes so many issues in the past too.
[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #33 from Vincent Lefèvre --- (In reply to Andrew Pinski from comment #32) > The runpath won't work because the libraries are installed yet. This is what libtool does for GNU MPFR, and this works fine. For instance, when building test programs, I can see: -Wl,-rpath -Wl,/home/vinc17/software/mpfr/src/.libs so that it doesn't need to change LD_LIBRARY_PATH. (The test programs don't need to be installed, so that using the path to the build directory will not yield any issue, but AFAIK, if need be, libtool supports relinking of programs to be installed.)
[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 Andrew Pinski changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED --- Comment #32 from Andrew Pinski --- (In reply to Vincent Lefèvre from comment #21) > But perhaps that instead, a run path should be used > together with --disable-new-dtags (so that it overrides the user's > LD_LIBRARY_PATH). The runpath won't work because the libraries are installed yet. This is whole forward vs backward compatibility issue really. libstdc++ is backwards compatible but not forwards compatible. Note Ada front-end has already a similar issue too. I don't see a way of fixing this without breaking everything.
[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #31 from Artem S. Tashkinov --- And one final tidbit, `make LD=ld.bfd install prefix=/tmp/GCC-11.3` fails: make[3]: Entering directory '/tmp/OBJDIR/libcc1' make[3]: Nothing to be done for 'install-exec-am'. /usr/bin/mkdir -p '/tmp/GCC-11.3/lib/../lib64' /bin/sh ./libtool --mode=install /usr/bin/install -c libcc1.la '/tmp/GCC-11.3/lib/../lib64' libtool: install: error: cannot install `libcc1.la' to a directory not ending in /opt/gcc/lib/../lib64 make[3]: *** [Makefile:496: install-cc1libLTLIBRARIES] Error 1 make[3]: Leaving directory '/tmp/OBJDIR/libcc1' make[2]: *** [Makefile:690: install-am] Error 2 make[2]: Leaving directory '/tmp/OBJDIR/libcc1' make[1]: *** [Makefile:15937: install-libcc1] Error 2 make[1]: Leaving directory '/tmp/OBJDIR' make: *** [Makefile:2483: install] Error 2
[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #30 from Artem S. Tashkinov ---
I'm not sure why certain headers file in the resulting build have changed:
diff -urN gcc/lib/gcc/x86_64-pc-linux-gnu/11/include/omp.h
gcc.123/lib/gcc/x86_64-pc-linux-gnu/11/include/omp.h
--- gcc/lib/gcc/x86_64-pc-linux-gnu/11/include/omp.h2022-07-05 18:10:45 UTC
+++ gcc.gold/lib/gcc/x86_64-pc-linux-gnu/11/include/omp.h 2022-05-22
10:48:25 UTC
@@ -46,8 +46,8 @@
typedef struct
{
- unsigned char _x[12]
-__attribute__((__aligned__(4)));
+ unsigned char _x[16]
+__attribute__((__aligned__(8)));
} omp_nest_lock_t;
#endif
diff -urN gcc/lib/gcc/x86_64-pc-linux-gnu/11/plugin/include/auto-host.h
gcc.123/lib/gcc/x86_64-pc-linux-gnu/11/plugin/include/auto-host.h
--- gcc/lib/gcc/x86_64-pc-linux-gnu/11/plugin/include/auto-host.h
2022-07-05 18:10:46 UTC
+++ gcc.gold/lib/gcc/x86_64-pc-linux-gnu/11/plugin/include/auto-host.h
2022-05-22 10:48:13 UTC
@@ -1662,7 +1662,7 @@
/* Define if your linker supports -z bndplt */
#ifndef USED_FOR_TARGET
-#define HAVE_LD_BNDPLT_SUPPORT 1
+/* #undef HAVE_LD_BNDPLT_SUPPORT */
#endif
@@ -1687,7 +1687,7 @@
/* Define to the level of your linker's compressed debug section support. */
#ifndef USED_FOR_TARGET
-#define HAVE_LD_COMPRESS_DEBUG 3
+#define HAVE_LD_COMPRESS_DEBUG 2
#endif
@@ -1765,7 +1765,7 @@
/* Define if your linker supports --push-state/--pop-state */
#ifndef USED_FOR_TARGET
-#define HAVE_LD_PUSHPOPSTATE_SUPPORT 1
+/* #undef HAVE_LD_PUSHPOPSTATE_SUPPORT */
#endif
@@ -2326,7 +2326,7 @@
/* Specify plugin linker */
#ifndef USED_FOR_TARGET
-#define PLUGIN_LD_SUFFIX "ld.bfd"
+#define PLUGIN_LD_SUFFIX "ld"
#endif
[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 Artem S. Tashkinov changed: What|Removed |Added Summary|Cannot build GCC 11.3 on|GCC 11.3 doesn't build with |Fedora 36 |the GNU gold linker ||(version 2.37-27.fc36) ||1.16: libstdc++.so.6: ||version `GLIBCXX_3.4.30' ||not found --- Comment #29 from Artem S. Tashkinov --- OK, it all works this way: make LD=ld.bfd GCC 11.3 build system is incompatible with the GNU gold linker. I've changed the bug report title to reflect this. Please, fix it for 11.4 or at least leave a note on your website.
