[Bug c/105688] New: Cannot build GCC 11.3 on Fedora 36

[Bug c/105688] New: Cannot build GCC 11.3 on Fedora 36

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

            Bug ID: 105688
           Summary: Cannot build GCC 11.3 on Fedora 36
           Product: gcc
           Version: 11.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: aros at gmx dot com
  Target Milestone: ---

When trying to make gcc-11.3.0.tar.xz:

/bin/sh /tmp/gcc-11.3.0/libgcc/../mkinstalldirs 32
/tmp/OBJDIR/./gcc/xgcc -B/tmp/OBJDIR/./gcc/ -B/opt/gcc/x86_64-pc-linux-gnu/bin/
-B/opt/gcc/x86_64-pc-linux-gnu/lib/ -isystem
/opt/gcc/x86_64-pc-linux-gnu/include -isystem
/opt/gcc/x86_64-pc-linux-gnu/sys-include   -fno-checking -O2  -g -O2 -pipe
-mtune=generic -DIN_GCC    -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wno-error=format-diag -Wno-format -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include  -fpic
-mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector  -shared -nodefaultlibs
-Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o
32/libgcc_s.so.1.tmp -g -O2 -pipe -mtune=generic -m32 -B./ _muldi3_s.o
_negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o
_clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o
_addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o
_negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o
_clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o
_popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o
_powidf2_s.o _powixf2_s.o _powitf2_s.o _mulhc3_s.o _mulsc3_s.o _muldc3_s.o
_mulxc3_s.o _multc3_s.o _divhc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o
_divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o
_fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o
_fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o
_floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o
_floatundixf_s.o _divdi3_s.o _moddi3_s.o _divmoddi4_s.o _udivdi3_s.o
_umoddi3_s.o _udivmoddi4_s.o _udiv_w_sdiv_s.o cpuinfo_s.o tf-signs_s.o
sfp-exceptions_s.o addtf3_s.o divtf3_s.o eqtf2_s.o getf2_s.o letf2_s.o
multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o
floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o
floatunditf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o
trunctfdf2_s.o trunctfxf2_s.o enable-execute-stack_s.o unwind-dw2_s.o
unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc &&
rm -f 32/libgcc_s.so && if [ -f 32/libgcc_s.so.1 ]; then mv -f 32/libgcc_s.so.1
32/libgcc_s.so.1.backup; else true; fi && mv 32/libgcc_s.so.1.tmp
32/libgcc_s.so.1 && (echo "/* GNU ld script"; echo "   Use the shared library,
but some functions are only in"; echo "   the static library.  */"; echo "GROUP
( libgcc_s.so.1 -lgcc )" ) > 32/libgcc_s.so
/usr/bin/ld:
/tmp/OBJDIR/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version
`GLIBCXX_3.4.30' not found (required by /usr/bin/ld)
collect2: error: ld returned 1 exit status
make[5]: *** [Makefile:995: libgcc_s.so] Error 1

I've no idea what to, please help.

[Bug c/105688] Cannot build GCC 11.3 on Fedora 36

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #1 from Artem S. Tashkinov <aros at gmx dot com> ---
In /tmp/OBJDIR/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs I replaced the built
libstdc++.so.29 _three times_ with the system one (libstdc++.so.30) and it all
worked.

Still this looks like a serious bug which is worth resolving.

Google doesn't find anything relevant, so people may get stuck.

[Bug c/105688] Cannot build GCC 11.3 on Fedora 36

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #2 from Artem S. Tashkinov <aros at gmx dot com> ---
This workaround of mine is not really good: after `make install` you end up
with /opt/gcc/lib64/libstdc++.so.6.0.29 which is not GCC's but the system one
(/usr/lib64/libstdc++.so.6.0.30.so).

[Bug c/105688] Cannot build GCC 11.3 on Fedora 36

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-05-22
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
How are you building gcc?
What configure options are being passed?
What make options are being passed?
Do you have any env variables set that might effect configure/make?
Are you building in the source directory or a different directory?

[Bug c/105688] Cannot build GCC 11.3 on Fedora 36

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #4 from Artem S. Tashkinov <aros at gmx dot com> ---
(In reply to Andrew Pinski from comment #3)
> How are you building gcc?
> What configure options are being passed?
> What make options are being passed?
> Do you have any env variables set that might effect configure/make?
> Are you building in the source directory or a different directory?

#! /bin/sh

WD=/tmp/OBJDIR
GD=`pwd`

export CFLAGS="-O2 -pipe -mtune=generic"
export CXXFLAGS=$CFLAGS
export LDFLAGS="-Wl,-O1"

mkdir -p "$WD" && cd "$WD" && \
"$GD"/configure --disable-stage1-checking --with-system-zlib \
--enable-languages="c,c++,lto" --prefix=/opt/gcc \
--disable-sjlj-exceptions --enable-newlib-io-long-long \
--with-gcc-major-version-only --without-isl --enable-multilib

nice make -j16

[Bug c/105688] Cannot build GCC 11.3 on Fedora 36

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #5 from Artem S. Tashkinov <aros at gmx dot com> ---
Using the official tar.xz file of course, without any
changes/modifications/patches.

[Bug c/105688] Cannot build GCC 11.3 on Fedora 36

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
The libgcc_s.so link shouldn't reference anything from libstdc++ so this is
really odd.

[Bug c/105688] Cannot build GCC 11.3 on Fedora 36

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |UNCONFIRMED
     Ever confirmed|1                           |0

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
/usr/bin/ld:
/tmp/OBJDIR/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version
`GLIBCXX_3.4.30' not found (required by /usr/bin/ld)


The problem is not realted to GCC directly but rather ld being linked against a
newer version of libstdc++ and now you just compiled an older version of
libstdc++ and that is in the LD_LIBRARY_PATH some how ...  Which should not
happen ....

If anything this should be reported to binutils and have ld (I suspect gold
here) use -static-libstdc++ -static-libgcc while linking just the same way GCC
does.

[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|2022-05-22 00:00:00         |2022-05-23
          Component|c                           |bootstrap

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Do you have the full log?

[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Also can you provide the full output of "env" ?

[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #10 from Artem S. Tashkinov <aros at gmx dot com> ---
(In reply to Andrew Pinski from comment #8)
> Do you have the full log?

The full build log? I can generate one right away.

(In reply to Andrew Pinski from comment #9)
> Also can you provide the full output of "env" ?

# env
SHELL=/bin/bash
HOSTNAME=fedora
PWD=/root
LOGNAME=root
HOME=/root
LANG=en_US.UTF-8
XDG_CACHE_HOME=/var/tmp/xdgcache-root
TERM=xterm-256color
LESSOPEN=||/usr/bin/lesspipe.sh %s
USER=root
SHLVL=1
DEBUGINFOD_URLS=https://debuginfod.fedoraproject.org/ 
which_declare=declare -f
PATH=/root/.local/bin:/root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/opt/wine/bin
MAIL=/var/spool/mail/root
BASH_FUNC_which%%=() {  ( alias;
 eval ${which_declare} ) | /usr/bin/which --tty-only --read-alias
--read-functions --show-tilde --show-dot $@
}
_=/usr/bin/env

[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #11 from Artem S. Tashkinov <aros at gmx dot com> ---
Created attachment 53020
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53020&action=edit
gcc-11.3.0.build.log.xz

[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36

[amonakov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

Alexander Monakov <amonakov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amonakov at gcc dot gnu.org

--- Comment #12 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #7)
> /usr/bin/ld:
> /tmp/OBJDIR/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6:
> version `GLIBCXX_3.4.30' not found (required by /usr/bin/ld)
> 
> 
> The problem is not realted to GCC directly but rather ld being linked
> against a newer version of libstdc++ and now you just compiled an older
> version of libstdc++ and that is in the LD_LIBRARY_PATH some how ...  Which
> should not happen ....

Could libtool be erroneously populating LD_LIBRARY_PATH?

> If anything this should be reported to binutils and have ld (I suspect gold
> here) use -static-libstdc++ -static-libgcc while linking just the same way
> GCC does.

No, this doesn't make sense, ld shouldn't work around wrong LD_LIBRARY_PATH
setting.

[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Can you run the following command:

LD_DEBUG=all LD_DEBUG_OUTPUT=ldout /tmp/OBJDIR/./gcc/xgcc -shared-libgcc
-B/tmp/OBJDIR/./gcc -nostdinc++
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs
-B/opt/gcc/x86_64-pc-linux-gnu/bin/ -B/opt/gcc/x86_64-pc-linux-gnu/lib/
-isystem /opt/gcc/x86_64-pc-linux-gnu/include -isystem
/opt/gcc/x86_64-pc-linux-gnu/sys-include -fno-checking  -m32  -fPIC -DPIC
-D_GLIBCXX_SHARED -shared -nostdlib /lib/../lib/crti.o
/tmp/OBJDIR/./gcc/32/crtbeginS.o  .libs/compatibility.o
.libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o
.libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o
.libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o
.libs/compatibility-condvar.o  -Wl,--whole-archive
../libsupc++/.libs/libsupc++convenience.a
../src/c++98/.libs/libc++98convenience.a
../src/c++11/.libs/libc++11convenience.a
../src/c++17/.libs/libc++17convenience.a
../src/c++20/.libs/libc++20convenience.a -Wl,--no-whole-archive 
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs -lm
-L/tmp/OBJDIR/./gcc/32 -L/lib/../lib -L/usr/lib/../lib -L/tmp/OBJDIR/./gcc -lc
-lgcc_s /tmp/OBJDIR/./gcc/32/crtendS.o /lib/../lib/crtn.o  -m32 -Wl,-O1 -Wl,-z
-Wl,relro -Wl,--gc-sections -m32 -Wl,--version-script=libstdc++-symbols.ver  
-Wl,-soname -Wl,libstdc++.so.6 -o .libs/libstdc++.so.6.0.29

In /tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src directory and provide
the ldout.* files?

I don't see anywhere where the
/tmp/OBJDIR/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/ directory should have
been added.

There should be no way the 32bit mutli-lib is referencing the libraries in the
64bit multi-lib directory at this point.

[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #14 from Artem S. Tashkinov <aros at gmx dot com> ---
Created attachment 53022
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53022&action=edit
lddebug.tar.xz

(In reply to Andrew Pinski from comment #13)
> Can you run the following command:
> 
> In /tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src directory and provide
> the ldout.* files?
>

[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #15 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Hmm, now this might be a libtool issue ....

[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #16 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Artem S. Tashkinov from comment #14)
> Created attachment 53022 [details]
> lddebug.tar.xz

Thanks this confirms that it is working like it should be and something is
setting LD_LIBRARY_PATH when it should not be ...
It definitely looks like a libtool issue. libtool is almost not maintained
either ...

[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36

[sam at gentoo dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |toolchain at gentoo dot org

--- Comment #17 from Sam James <sam at gentoo dot org> ---
libtool recently got a new maintainer and had a new release (2.4.7). It's
possible 2.4.7 is related.

[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #18 from Artem S. Tashkinov <aros at gmx dot com> ---
(In reply to Sam James from comment #17)
> libtool recently got a new maintainer and had a new release (2.4.7). It's
> possible 2.4.7 is related.

Fedora 36 still features an old version: libtool-2.4.6-50.fc36.x86_64

Here's its changelog: https://src.fedoraproject.org/rpms/libtool/commits/f36

[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #19 from Artem S. Tashkinov <aros at gmx dot com> ---
I'm curious: Fedora 36 takes probably half an hour to be downloaded and
installed in a VM/chroot/etc., so you could probably debug the issue in a few
minutes ;-)

[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #20 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note gcc sources have its own local copy of libtool so it does not matter what
the distros have.

[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36

[vincent-gcc at vinc17 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #21 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
I have a similar issue under Debian/unstable with GCC old of a few months,
where in x86_64-pc-linux-gnu/libstdc++-v3/po, msgfmt fails with an error like

/usr/bin/msgfmt:
/home/vlefevre/software/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6:
version `GLIBCXX_3.4.30' not found (required by
/usr/lib/x86_64-linux-gnu/libicuuc.so.71)

A msgfmt wrapper with "printenv LD_LIBRARY_PATH" shows that LD_LIBRARY_PATH is
set to

/home/vlefevre/software/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs:/home/vlefevre/software/gcc-build/x86_64-pc-linux-gnu/libsanitizer/.libs:/home/vlefevre/software/gcc-build/x86_64-pc-linux-gnu/libvtv/.libs:/home/vlefevre/software/gcc-build/x86_64-pc-linux-gnu/libssp/.libs:/home/vlefevre/software/gcc-build/x86_64-pc-linux-gnu/libgomp/.libs:/home/vlefevre/software/gcc-build/x86_64-pc-linux-gnu/libitm/.libs:/home/vlefevre/software/gcc-build/x86_64-pc-linux-gnu/libatomic/.libs:/home/vlefevre/software/gcc-build/./gcc:/home/vlefevre/software/gcc-build/./prev-gcc

This bug is probably still present in master: I do not get any failure,
probably because the built libstdc++.so.6 is recent enough to be similar to the
one currently provided by Debian/unstable, but the wrapper still shows that
LD_LIBRARY_PATH is set to the above string (or similar), so that the bug could
still occur when the system libstdc++.so.6 gets something new.

I suppose that LD_LIBRARY_PATH is set because it is needed in order to use
built libraries. 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).

[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #22 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Artem S. Tashkinov from comment #19)
> I'm curious: Fedora 36 takes probably half an hour to be downloaded and
> installed in a VM/chroot/etc., so you could probably debug the issue in a
> few minutes ;-)

GCC 11.3 builds fine for me on F36.

[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #23 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Vincent Lefèvre from comment #21)
> I suppose that LD_LIBRARY_PATH is set because it is needed in order to use
> built libraries.

It is not needed except when running the testsuite, and should not be set.

[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36

[sam at gentoo dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #24 from Sam James <sam at gentoo dot org> ---
(In reply to Vincent Lefèvre from comment #21)
> I have a similar issue under Debian/unstable with GCC old of a few months,
> where in x86_64-pc-linux-gnu/libstdc++-v3/po, msgfmt fails with an error like
> 
> /usr/bin/msgfmt:
> /home/vlefevre/software/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/
> libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by
> /usr/lib/x86_64-linux-gnu/libicuuc.so.71)
> 

This issue is, I think, slightly different: https://bugs.gentoo.org/843119. It
might end up being related but I've only ever seen *that* issue in the context
of installing libstdc++ when doing the gcc build when NLS is enabled and using
a newer GCC to do the build of an older version.

[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #25 from Artem S. Tashkinov <aros at gmx dot com> ---
(In reply to Jonathan Wakely from comment #22)
> (In reply to Artem S. Tashkinov from comment #19)
> > I'm curious: Fedora 36 takes probably half an hour to be downloaded and
> > installed in a VM/chroot/etc., so you could probably debug the issue in a
> > few minutes ;-)
> 
> GCC 11.3 builds fine for me on F36.

Can you please try with the script I posted in comment #4?

[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36

[vincent-gcc at vinc17 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #26 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Jonathan Wakely from comment #23)
> (In reply to Vincent Lefèvre from comment #21)
> > I suppose that LD_LIBRARY_PATH is set because it is needed in order to use
> > built libraries.
> 
> It is not needed except when running the testsuite, and should not be set.

Indeed, for most projects. IIRC, for some project (was it Subversion?), using
built libraries was needed also during a part of the build, but that said,
since this is rather specific, this is probably not a reason to change
LD_LIBRARY_PATH globally, in case this is what libtool does.

(In reply to Sam James from comment #24)
> (In reply to Vincent Lefèvre from comment #21)
> > I have a similar issue under Debian/unstable with GCC old of a few months,
> > where in x86_64-pc-linux-gnu/libstdc++-v3/po, msgfmt fails with an error like
> > 
> > /usr/bin/msgfmt:
> > /home/vlefevre/software/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/
> > libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by
> > /usr/lib/x86_64-linux-gnu/libicuuc.so.71)
> 
> This issue is, I think, slightly different: https://bugs.gentoo.org/843119.

I think that the cause is the same (and the fix should be the same):
LD_LIBRARY_PATH is changed somewhere to point to some build directories. As
mentioned by https://bugs.gentoo.org/843119#c10 this shouldn't be done there.

> It might end up being related but I've only ever seen *that* issue in the
> context of installing libstdc++ when doing the gcc build when NLS is enabled
> and using a newer GCC to do the build of an older version.

While disabling NLS (Gentoo's fix) would be OK for most testing of older GCC, I
doubt that this is the right solution.

[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #27 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Artem S. Tashkinov from comment #25)
> Can you please try with the script I posted in comment #4?

That works fine on F35 and F36.

[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #28 from Artem S. Tashkinov <aros at gmx dot com> ---
(In reply to Jonathan Wakely from comment #27)
> (In reply to Artem S. Tashkinov from comment #25)
> > Can you please try with the script I posted in comment #4?
> 
> That works fine on F35 and F36.

I've just tried again, the result is the same. I have 100% standard Fedora 36
(sans a few custom environment variables defined - see below, nothing GCC
related) with all the updates installed.

The below commands are all run under the root user (not sudo, an actual login
under root).

# md5sum gcc-11.3.0.tar.xz 
4ee3e8c4c99e7b3444eb79f00f5f7a7e  gcc-11.3.0.tar.xz

# ld --version
GNU gold (version 2.37-27.fc36) 1.16

# gcc --version
gcc (GCC) 12.1.1 20220507 (Red Hat 12.1.1-1)

# ./build.sh
... skipped ...
libtool: compile:  /tmp/OBJDIR/./gcc/xgcc -shared-libgcc -B/tmp/OBJDIR/./gcc
-nostdinc++ -L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs
-B/opt/gcc/x86_64-pc-linux-gnu/bin/ -B/opt/gcc/x86_64-pc-linux-gnu/lib/
-isystem /opt/gcc/x86_64-pc-linux-gnu/include -isystem
/opt/gcc/x86_64-pc-linux-gnu/sys-include -fno-checking -m32
-I/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/include
-I/tmp/gcc-11.3.0/libstdc++-v3/libsupc++ -std=gnu++98 -fPIC -DPIC
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=compatibility.lo -g -O2 -pipe -mtune=generic -D_GNU_SOURCE -m32
-fcf-protection -mshstk -c
/tmp/gcc-11.3.0/libstdc++-v3/src/c++98/compatibility.cc -o compatibility.o
>/dev/null 2>&1
/bin/sh ../libtool --tag CXX   --mode=link /tmp/OBJDIR/./gcc/xgcc
-shared-libgcc -B/tmp/OBJDIR/./gcc -nostdinc++
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs
-B/opt/gcc/x86_64-pc-linux-gnu/bin/ -B/opt/gcc/x86_64-pc-linux-gnu/lib/
-isystem /opt/gcc/x86_64-pc-linux-gnu/include -isystem
/opt/gcc/x86_64-pc-linux-gnu/sys-include -fno-checking  -m32  -Wl,-O1
-Wl,-z,relro -Wl,--gc-sections  -std=gnu++98 -fPIC -DPIC
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=libstdc++.la  '-m32' -o libstdc++.la -version-info 6:29:0
-Wl,--version-script=libstdc++-symbols.ver -lm  -rpath /opt/gcc/lib/../lib
compatibility.lo compatibility-debug_list.lo compatibility-debug_list-2.lo 
compatibility-c++0x.lo compatibility-atomic-c++0x.lo
compatibility-thread-c++0x.lo compatibility-chrono.lo compatibility-condvar.lo 
 ../libsupc++/libsupc++convenience.la ../src/c++98/libc++98convenience.la
../src/c++11/libc++11convenience.la ../src/c++17/libc++17convenience.la
../src/c++20/libc++20convenience.la 
libtool: link: /tmp/OBJDIR/./gcc/xgcc -shared-libgcc -B/tmp/OBJDIR/./gcc
-nostdinc++ -L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs
-B/opt/gcc/x86_64-pc-linux-gnu/bin/ -B/opt/gcc/x86_64-pc-linux-gnu/lib/
-isystem /opt/gcc/x86_64-pc-linux-gnu/include -isystem
/opt/gcc/x86_64-pc-linux-gnu/sys-include -fno-checking  -m32  -fPIC -DPIC
-D_GLIBCXX_SHARED -shared -nostdlib /lib/../lib/crti.o
/tmp/OBJDIR/./gcc/32/crtbeginS.o  .libs/compatibility.o
.libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o
.libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o
.libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o
.libs/compatibility-condvar.o  -Wl,--whole-archive
../libsupc++/.libs/libsupc++convenience.a
../src/c++98/.libs/libc++98convenience.a
../src/c++11/.libs/libc++11convenience.a
../src/c++17/.libs/libc++17convenience.a
../src/c++20/.libs/libc++20convenience.a -Wl,--no-whole-archive 
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs -lm
-L/tmp/OBJDIR/./gcc/32 -L/lib/../lib -L/usr/lib/../lib -L/tmp/OBJDIR/./gcc -lc
-lgcc_s /tmp/OBJDIR/./gcc/32/crtendS.o /lib/../lib/crtn.o  -m32 -Wl,-O1 -Wl,-z
-Wl,relro -Wl,--gc-sections -m32 -Wl,--version-script=libstdc++-symbols.ver  
-Wl,-soname -Wl,libstdc++.so.6 -o .libs/libstdc++.so.6.0.29
/usr/bin/ld:
/tmp/OBJDIR/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version
`GLIBCXX_3.4.30' not found (required by /usr/bin/ld)
collect2: error: ld returned 1 exit status
make[10]: *** [Makefile:732: libstdc++.la] Error 1
make[10]: Leaving directory
'/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src'
make[9]: *** [Makefile:765: all-recursive] Error 1
make[9]: Leaving directory
'/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src'
make[8]: *** [Makefile:568: all-recursive] Error 1
make[8]: Leaving directory '/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3'
make[7]: *** [Makefile:493: all] Error 2
make[7]: Leaving directory '/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3'
make[6]: *** [Makefile:862: multi-do] Error 1
make[6]: Leaving directory '/tmp/OBJDIR/x86_64-pc-linux-gnu/libstdc++-v3'
make[5]: *** [Makefile:832: all-multi] Error 2
make[5]: Leaving directory '/tmp/OBJDIR/x86_64-pc-linux-gnu/libstdc++-v3'
make[4]: *** [Makefile:568: all-recursive] Error 1
make[4]: Leaving directory '/tmp/OBJDIR/x86_64-pc-linux-gnu/libstdc++-v3'
make[3]: *** [Makefile:493: all] Error 2
make[3]: Leaving directory '/tmp/OBJDIR/x86_64-pc-linux-gnu/libstdc++-v3'
make[2]: *** [Makefile:16953: all-stage1-target-libstdc++-v3] Error 2
make[2]: Leaving directory '/tmp/OBJDIR'
make[1]: *** [Makefile:23946: stage1-bubble] Error 2
make[1]: Leaving directory '/tmp/OBJDIR'
make: *** [Makefile:1014: all] Error 2

# set
BASH=/usr/bin/bash
BASHOPTS=checkwinsize:cmdhist:complete_fullquote:expand_aliases:extquote:force_fignore:globasciiranges:histappend:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath
BASHRCSOURCED=Y
BASH_ALIASES=()
BASH_ARGC=([0]="0")
BASH_ARGV=()
BASH_CMDS=()
BASH_LINENO=()
BASH_REMATCH=([0]="/root/.local/bin:/root/bin:")
BASH_SOURCE=()
BASH_VERSINFO=([0]="5" [1]="1" [2]="16" [3]="1" [4]="release"
[5]="x86_64-redhat-linux-gnu")
BASH_VERSION='5.1.16(1)-release'
COLUMNS=254
DEBUGINFOD_URLS='https://debuginfod.fedoraproject.org/ '
DIRSTACK=()
EUID=0
FREETYPE_PROPERTIES=truetype:interpreter-version=35
GROUPS=()
HISTCONTROL=ignoredups:ignorespace
HISTFILE=/root/.bash_history
HISTFILESIZE=33333
HISTSIZE=33333
HOME=/root
HOSTNAME=zen
HOSTTYPE=x86_64
IFS=$' \t\n'
LANG=en_US.UTF-8
LESSOPEN='||/usr/bin/lesspipe.sh %s'
LINES=66
LOGNAME=root
LS_COLORS=<skipped>
MACHTYPE=x86_64-redhat-linux-gnu
MAIL=/var/spool/mail/root
MAILCHECK=60
MC_SID=1057166
MC_TMPDIR=/var/tmp/mc-root
OLDPWD=/mnt/loop/Linux/kernel
OPTERR=1
OPTIND=1
OSTYPE=linux-gnu
PATH=/root/.local/bin:/root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/opt/wine/bin
PIPESTATUS=([0]="2")
PPID=1057164
PROMPT_COMMAND=$'printf "\\033]0;%s@%s:%s\\007" "${USER}" "${HOSTNAME%%.*}"
"${PWD/#$HOME/\\~}"\npwd>&9;kill -STOP $$'
PS1='[\u@\h \W]\$ '
PS2='> '
PS4='+ '
PWD=/tmp/gcc-11.3.0
QML_DISABLE_DISK_CACHE=1
QT_AUTO_SCREEN_SCALE_FACTOR=0
QT_FONT_DPI=100
SHELL=/bin/bash
SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor
SHLVL=2
TERM=xterm-256color
UID=0
USER=root
XDG_CACHE_HOME=/var/tmp/xdgcache-root
_=./build.sh
__GL_ExperimentalPerfStrategy=1
colors=/root/.dircolors
which_declare='declare -f'
which_opt=-f

[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

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

Artem S. Tashkinov <aros at gmx dot com> 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 <aros at gmx dot com> ---
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.

[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

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #30 from Artem S. Tashkinov <aros at gmx dot com> ---
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.h    2022-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

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #31 from Artem S. Tashkinov <aros at gmx dot com> ---
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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|1                           |0
             Status|WAITING                     |UNCONFIRMED

--- Comment #32 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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

[vincent-gcc at vinc17 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #33 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #34 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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

[vincent-gcc at vinc17 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #35 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
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

[vincent-gcc at vinc17 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #36 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #37 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #38 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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

[vincent-gcc at vinc17 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #39 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(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

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #40 from Artem S. Tashkinov <aros at gmx dot com> ---
(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

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #41 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #42 from Artem S. Tashkinov <aros at gmx dot com> ---
(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

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

--- Comment #43 from Jonathan Wakely <redi at gcc dot gnu.org> ---
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

[arsen at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

Arsen Arsenović <arsen at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |romain.geissler at amadeus dot com

--- Comment #44 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
*** 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

[arsen at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

Arsen Arsenović <arsen at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |arsen at gcc dot gnu.org

--- Comment #45 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
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 breaks build process if bootstrapping a downgraded GCC (was "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")

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|2022-05-23 00:00:00         |2024-01-24
             Status|UNCONFIRMED                 |NEW

[Bug bootstrap/105688] GCC breaks build process if bootstrapping a downgraded GCC (was "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")

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=41818
                 CC|                            |jason at gcc dot gnu.org

--- Comment #46 from Jason Merrill <jason at gcc dot gnu.org> ---
The problematic line in the toplevel Makefile is

        $(RPATH_ENVVAR)=`echo "$(TARGET_LIB_PATH)$$$(RPATH_ENVVAR)" | sed
's,::*,:,g;s,^:*,,;s,:*$$,,'`; export $(RPATH_ENVVAR); \

The patch for PR22340 moved this from POSTSTAGE1_HOST_EXPORTS to HOST_EXPORTS,
but didn't mention that in its ChangeLog.   Which extended this issue to stage1
builds as well.

The rationale for doing this at all seems to be in order to make a just-built
tool find the just-built shared libraries that it links agains, but this also
affects pre-built tools that link against other versions of the same libraries.

And it doesn't justify adding target libraries in stage1.

For bfd/opcodes, it would seem better to set LD_LIBRARY_PATH in exec-tool.in so
that it only affects those tools specifically.  But if the new gcc links
against shared libmpc and such, that won't work, since if we set
LD_LIBRARY_PATH for gcc it's also set for the other tools it calls.

A fix for various system binutils might be to use exec-tool.in to splice out
the build directory from LD_LIBRARY_PATH.  But again, that won't help with my
system gcc.

I'm not sure what the best approach is for stage2+, where you might need to
load the previous libstdc++ for just-built tools.  I guess the splicing in
exec-tool.in would cover that as well, and in that case we don't need to worry
about system gcc.

For the moment I think I'm just going to propose reverting that bit of the
PR22340 fix.

[Bug bootstrap/105688] GCC breaks build process if bootstrapping a downgraded GCC (was "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")

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=87858

--- Comment #47 from Jason Merrill <jason at gcc dot gnu.org> ---
Also see https://gcc.gnu.org/legacy-ml/gcc/2012-06/msg00325.html for an
argument to stop adding the target libs to LD_LIBRARY_PATH entirely.