On Sat, 2021-06-19 at 11:45 +0900, Kazuyoshi Furutaka via Gcc-help
wrote:
> Hi all...
>
> From: Jim Wilson <jimw@xxxxxxxxxx>
> Subject: Re: Problem building older versions of gcc
> Date: Mon, 14 Jun 2021 14:12:29 -0700
>
> > On Sat, Jun 12, 2021 at 3:39 AM Kazuyoshi Furutaka via Gcc-help <
>
> > gcc-help@xxxxxxxxxxx> wrote:
>
> >
>
> > > > cc1plus shouldn't link to libstdc++.so. Instead it links to
> > > > static
>
> > > > library libstdc++.a (at least by default).
>
> > >
>
> >
>
> > But it does link with system libraries, and one of them could in
> > turn have
>
> > been linked with the system libstdc++ which is newer than the one
> > you are
>
> > building. So you need to find what system library linked into
> > cc1plus
>
> > requires the system libstdc++. You should be able to do that with
> > the ldd
>
> > program, e.g. "ldd cc1plus" will show you what libraries are linked
> > in,
>
> > then run ldd on each library those use recursively, until you find
> > the one
>
> > that needs the newer libstdc++. Then, depending on exactly which
> > library
>
> > that is, either you add a configure option to avoid using it, or you
> > add
>
> > the sources into the gcc build tree to build your own version of it,
> > or you
>
> > manually build a version of it that you can use with an older gcc.
>
> > Possible libraries to look at are gmp, mpc, mpfr, isl, z, m, c, dl.
> > There
>
> > could be others depending on what configure options you used.
>
> >
>
> > Jim
>
>
> Well... I now think I misunderstood...
>
> From: Kazuyoshi Furutaka via Gcc-help <gcc-help@xxxxxxxxxxx>
> Subject: Problem building older versions of gcc
> Date: Fri, 04 Jun 2021 22:30:51 +0900 (JST)
>
> > mkdir -p ./x86_64-pc-linux-gnu/bits/stdc++.h.gch
>
> > /home/furutaka/work/gcc/gcc-10.3.0-bld/./gcc/xgcc -shared-libgcc -
> > B/home/furutaka/work/gcc/gcc-10.3.0-bld/./gcc -nostdinc++ -
> > L/home/furutaka/work/gcc/gcc-10.3.0-bld/x86_64-pc-linux-
> > gnu/32/libstdc++-v3/src -L/home/furutaka/work/gcc/gcc-10.3.0-
> > bld/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs -
> > L/home/furutaka/work/gcc/gcc-10.3.0-bld/x86_64-pc-linux-
> > gnu/32/libstdc++-v3/libsupc++/.libs -B/usr/local/gcc/10.3.0/x86_64-
> > pc-linux-gnu/bin/ -B/usr/local/gcc/10.3.0/x86_64-pc-linux-gnu/lib/ -
> > isystem /usr/local/gcc/10.3.0/x86_64-pc-linux-gnu/include -isystem
> > /usr/local/gcc/10.3.0/x86_64-pc-linux-gnu/sys-include -fno-checking
> > -m32 -x c++-header -nostdinc++ -g -O2 -D_GNU_SOURCE -m32 -
> > I/home/furutaka/work/gcc/gcc-10.3.0-bld/x86_64-pc-linux-
> > gnu/32/libstdc++-v3/include/x86_64-pc-linux-gnu -
> > I/home/furutaka/work/gcc/gcc-10.3.0-bld/x86_64-pc-linux-
> > gnu/32/libstdc++-v3/include -I/home/furutaka/work/gcc/gcc-
> > 10.3.0/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x
> > /home/furutaka/work/gcc/gcc-10.3.0/libstdc++-
> > v3/include/precompiled/stdc++.h \
>
> > -o x86_64-pc-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch
>
> > /home/furutaka/work/gcc/gcc-10.3.0-bld/./gcc/cc1plus:
> > /home/furutaka/work/gcc/gcc-10.3.0-bld/x86_64-pc-linux-
> > gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version `GLIBCXX_3.4.29'
> > not found (required by /home/furutaka/work/gcc/gcc-10.3.0-
> > bld/./gcc/cc1plus)
>
> > make[9]: *** [Makefile:1824: x86_64-pc-linux-
> > gnu/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1
>
> > make[9]: Leaving directory '/home/furutaka/work/gcc/gcc-10.3.0-
> > bld/x86_64-pc-linux-gnu/32/libstdc++-v3/include'
>
> > make[8]: *** [Makefile:563: all-recursive] Error 1
>
> > make[8]: Leaving directory '/home/furutaka/work/gcc/gcc-10.3.0-
> > bld/x86_64-pc-linux-gnu/32/libstdc++-v3'
>
> > make[7]: *** [Makefile:488: all] Error 2
>
> > make[7]: Leaving directory '/home/furutaka/work/gcc/gcc-10.3.0-
> > bld/x86_64-pc-linux-gnu/32/libstdc++-v3'
>
> > make[6]: *** [Makefile:856: multi-do] Error 1
>
> > make[6]: Leaving directory '/home/furutaka/work/gcc/gcc-10.3.0-
> > bld/x86_64-pc-linux-gnu/libstdc++-v3'
>
> > make[5]: *** [Makefile:824: all-multi] Error 2
>
> > make[5]: Leaving directory '/home/furutaka/work/gcc/gcc-10.3.0-
> > bld/x86_64-pc-linux-gnu/libstdc++-v3'
>
> > make[4]: *** [Makefile:563: all-recursive] Error 1
>
> > make[4]: Leaving directory '/home/furutaka/work/gcc/gcc-10.3.0-
> > bld/x86_64-pc-linux-gnu/libstdc++-v3'
>
> > make[3]: *** [Makefile:488: all] Error 2
>
> > make[3]: Leaving directory '/home/furutaka/work/gcc/gcc-10.3.0-
> > bld/x86_64-pc-linux-gnu/libstdc++-v3'
>
> > make[2]: *** [Makefile:19986: all-stage1-target-libstdc++-v3] Error
> > 2
>
> > make[2]: Leaving directory '/home/furutaka/work/gcc/gcc-10.3.0-bld'
>
> > make[1]: *** [Makefile:28047: stage1-bubble] Error 2
>
> > make[1]: Leaving directory '/home/furutaka/work/gcc/gcc-10.3.0-bld'
>
> > make: *** [Makefile:1007: all] Error 2
>
>
> The above clearly indicates that the error was in building
> stage-1 compiler (make targets are "stage1-bubble" which depends
> on "all-stage1-target-libstdc++-v3"), and I think it's OK that
> the cc1plus made in the stage-1 depends on the libraries on which
> gcc is building (experts, am I correct?).
>
> Indeed, on a Fedora 33 system which is runnning on QEMU/KVM
> and was installed for testing the builds (in the system,
> a group of packages named "Development Tools", and gcc-c++
> and glibc-devel.i686 packages are installed),
> the build of gcc-10.2.0 was successful and there're 3 cc1plus'es:
>
> > [furutaka@localhost gcc-10.2.0-bld]$ ldd `find . -name cc1plus`
>
> > ./stage1-gcc/cc1plus:
>
> > linux-vdso.so.1 (0x00007ffc76bac000)
>
> > libdl.so.2 => /lib64/libdl.so.2 (0x00007f13ab8e8000)
>
> > libstdc++.so.6 => /lib64/libstdc++.so.6
> > (0x00007f13ab700000)
>
> > libm.so.6 => /lib64/libm.so.6 (0x00007f13ab5b8000)
>
> > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f13ab598000)
>
> > libc.so.6 => /lib64/libc.so.6 (0x00007f13ab3c8000)
>
> > /lib64/ld-linux-x86-64.so.2 (0x00007f13ab908000)
>
> > ./gcc/cc1plus:
>
> > linux-vdso.so.1 (0x00007ffc1af64000)
>
> > libdl.so.2 => /lib64/libdl.so.2 (0x00007f896ea58000)
>
> > libm.so.6 => /lib64/libm.so.6 (0x00007f896e910000)
>
> > libc.so.6 => /lib64/libc.so.6 (0x00007f896e740000)
>
> > /lib64/ld-linux-x86-64.so.2 (0x00007f896ea78000)
>
> > ./prev-gcc/cc1plus:
>
> > linux-vdso.so.1 (0x00007ffc1a2cc000)
>
> > libdl.so.2 => /lib64/libdl.so.2 (0x00007f7a3caf8000)
>
> > libm.so.6 => /lib64/libm.so.6 (0x00007f7a3c9b0000)
>
> > libc.so.6 => /lib64/libc.so.6 (0x00007f7a3c7e0000)
>
> > /lib64/ld-linux-x86-64.so.2 (0x00007f7a3cb18000)
>
> that is, the stage-1 cc1plus depends on /lib64/libstdc++.so.6.
>
> But, on a Fedora-34 system which is running on QEMU/KVM and
> (almost) the same packages are installed, the build of gcc-10.2.0
> (as well as gcc-10.3.0) failed on stage-1. (On Fedora-34 system
> the system gcc is 10.3.1, so I've tried to build gcc-10.2.0 on
> both system to see the differences.)
>
> Indeed, on the Fedora-34 system,
> > LD_PRELOAD=/lib64/libstdc++.so.6 make all-stage1-target-
> > libstdc++-v3
>
> and successive build of the remaining was successful!
>
> In addition, on the Fedora-34 system, after installing
> > libstdc++-static
>
> package (which of course include libstdc++.a static library),
> the make of gcc-10.2.0 configured with merely
> > --prefix=/usr/local/gcc/10.2.0
>
> was successful; which is due to the following constructs in the
> top-level configure:
>
> > # Check whether --with-stage1-ldflags was given.
>
> > if test "${with_stage1_ldflags+set}" = set; then :
>
> > withval=$with_stage1_ldflags; if test "$withval" = "no" -o
> > "$withval" = "yes"; then
>
> > stage1_ldflags=
>
> > else
>
> > stage1_ldflags=$withval
>
> > fi
>
> > else
>
> > stage1_ldflags=
>
> > # In stage 1, default to linking libstdc++ and libgcc statically
> > with GCC
>
> > # if supported. But if the user explicitly specified the
> > libraries to use,
>
> > # trust that they are doing what they want.
>
> > if test "$with_static_standard_libraries" = yes -a "$stage1_libs"
> > = "" \
>
> > -a "$have_static_libs" = yes; then
>
> > stage1_ldflags="-static-libstdc++ -static-libgcc"
>
> > fi
>
> > fi
>
>
>
> Then, the problem can be said as the following:
> "Why isn't /lib64/libstdc++.so.6 found on Fedora-34 systems
> (although it's found on Fedora-33)"
I think gcc building system is setting LD_LIBRARY_PATH somewhere. So
during building process the newly built libstdc++.so.6 is found, instead
of the system library.
On Fedora 33 there should be the same problem. But Fedora 33 may have a
same libstdc++.so.6 version with gcc-10.x, so the newly built library is
compatible completely with the system one and no issue is observed.
Anyway, GCC executables should not link to libstdc++.so.6. Is
libstdc++.a installed on your Fedora 34? Note that Fedora maintainers
may split it into a seperate package.
--
Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx>
School of Aerospace Science and Technology, Xidian University
