public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* Problem building older versions of gcc
@ 2021-06-04 13:30 Kazuyoshi Furutaka
  2021-06-04 14:20 ` Jonathan Wakely
  2021-06-12  7:37 ` Kazuyoshi Furutaka
  0 siblings, 2 replies; 14+ messages in thread
From: Kazuyoshi Furutaka @ 2021-06-04 13:30 UTC (permalink / raw)
  To: gcc-help

Dear experts...

I'm having troubles building GCC 10.3.0 (and a few
older versions) with the newer one.

The system is Fedora release 34 (Thirty Four), x86_64.
The installed gcc version is:
  gcc (GCC) 11.1.1 20210428 (Red Hat 11.1.1-1)

I downloaded gcc-10.3.0.tar.xz and expand it, and then
did
  `../gcc-10.3.0/configure --prefix=/usr/local/gcc/10.3.0`
from another directory, and `make`.

The make failed as the following (the same occured for
10.2.0, 10.1.0, and 9.4.0).

...
make[7]: Entering directory '/home/furutaka/work/gcc/gcc-10.3.0-bld/x86_64-pc-linux-gnu/32/libstdc++-v3'
make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CC_FOR_TARGET=/home/furutaka/work/gcc/gcc-10.3.0-bld/./gcc/xgcc -B/home/furutaka/work/gcc/gcc-10.3.0-bld/./gcc/" "CFLAGS=-g -O2  -m32" "CXXFLAGS=-g -O2 -D_GNU_SOURCE  -m32" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g -O2" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS=-m32" "LIBCFLAGS=-g -O2  -m32" "LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=make" "MAKEINFO=makeinfo --split-size=5000000 --split-size=5000000 --split-size=5000000     " "SHELL=/bin/sh" "RUNTESTFLAGS=" "exec_prefix=/usr/local/gcc/10.3.0" "infodir=/usr/local/gcc/10.3.0/share/info" "libdir=/usr/local/gcc/10.3.0/lib" "includedir=/usr/local/gcc/10.3.0/include" "prefix=/usr/local/gcc/10.3.0" "tooldir=/usr/local/gcc/10.3.0/x86_64-pc-linux-gnu" "gxx_include_dir=/usr/local/gcc/10.3.0/include/c++/10.3.0" "AR=ar" "AS=/home/furutaka/work/gcc/gcc-10.3.0-bld/./gcc/as" "LD=/home/furutaka/work/gcc/gcc-10.3.0-bld/./gcc/collect-ld" "RANLIB=ranlib" "NM=/home/furutaka/work/gcc/gcc-10.3.0-bld/./gcc/nm" "NM_FOR_BUILD=" "NM_FOR_TARGET=nm" "DESTDIR=" "WERROR=" all-recursive
make[8]: Entering directory '/home/furutaka/work/gcc/gcc-10.3.0-bld/x86_64-pc-linux-gnu/32/libstdc++-v3'
Making all in include
make[9]: Entering directory '/home/furutaka/work/gcc/gcc-10.3.0-bld/x86_64-pc-linux-gnu/32/libstdc++-v3/include'
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


It seems to me that at some point of the build, for some
reasons the already installed libstdc++ which contain
GLIBCXX_3.4.29 was referenced or used in the currently
building system...


[furutaka@peart-furu-or-jp gcc-10.3.0-bld]$ strings /home/furutaka/work/gcc/gcc-10.3.0-bld/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6 | grep "^GLIBCXX_3.4.2." | sort | uniq
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25
GLIBCXX_3.4.26
GLIBCXX_3.4.27
GLIBCXX_3.4.28

[furutaka@peart-furu-or-jp gcc-10.3.0-bld]$ strings /lib64/libstdc++.so.6 | grep "^GLIBCXX_3.4.2." | sort | uniq
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25
GLIBCXX_3.4.26
GLIBCXX_3.4.27
GLIBCXX_3.4.28
GLIBCXX_3.4.29

How do I fix this?

Thanks in advance...

Kazuyoshi
--
Kazuyoshi Furutaka
furutaka@jb3.so-net.ne.jp

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problem building older versions of gcc
  2021-06-04 13:30 Problem building older versions of gcc Kazuyoshi Furutaka
@ 2021-06-04 14:20 ` Jonathan Wakely
  2021-06-04 14:26   ` Kazuyoshi Furutaka
  2021-06-12  7:37 ` Kazuyoshi Furutaka
  1 sibling, 1 reply; 14+ messages in thread
From: Jonathan Wakely @ 2021-06-04 14:20 UTC (permalink / raw)
  To: Kazuyoshi Furutaka; +Cc: gcc-help

On Fri, 4 Jun 2021 at 14:32, Kazuyoshi Furutaka via Gcc-help
<gcc-help@gcc.gnu.org> wrote:
>
> Dear experts...
>
> I'm having troubles building GCC 10.3.0 (and a few
> older versions) with the newer one.
>
> The system is Fedora release 34 (Thirty Four), x86_64.
> The installed gcc version is:
>   gcc (GCC) 11.1.1 20210428 (Red Hat 11.1.1-1)
>
> I downloaded gcc-10.3.0.tar.xz and expand it, and then
> did
>   `../gcc-10.3.0/configure --prefix=/usr/local/gcc/10.3.0`
> from another directory, and `make`.
>
> The make failed as the following (the same occured for
> 10.2.0, 10.1.0, and 9.4.0).
>
> ...
> make[7]: Entering directory '/home/furutaka/work/gcc/gcc-10.3.0-bld/x86_64-pc-linux-gnu/32/libstdc++-v3'
> make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CC_FOR_TARGET=/home/furutaka/work/gcc/gcc-10.3.0-bld/./gcc/xgcc -B/home/furutaka/work/gcc/gcc-10.3.0-bld/./gcc/" "CFLAGS=-g -O2  -m32" "CXXFLAGS=-g -O2 -D_GNU_SOURCE  -m32" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g -O2" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS=-m32" "LIBCFLAGS=-g -O2  -m32" "LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=make" "MAKEINFO=makeinfo --split-size=5000000 --split-size=5000000 --split-size=5000000     " "SHELL=/bin/sh" "RUNTESTFLAGS=" "exec_prefix=/usr/local/gcc/10.3.0" "infodir=/usr/local/gcc/10.3.0/share/info" "libdir=/usr/local/gcc/10.3.0/lib" "includedir=/usr/local/gcc/10.3.0/include" "prefix=/usr/local/gcc/10.3.0" "tooldir=/usr/local/gcc/10.3.0/x86_64-pc-linux-gnu" "gxx_include_dir=/usr/local/gcc/10.3.0/include/c++/10.3.0" "AR=ar" "AS=/home/furutaka/work/gcc/gcc-10.3.0-bld/./gcc/as" "LD=/home/furutaka/work/gcc/gcc-10.3.0-bld/./gcc/collect-ld" "RANLIB=ranlib" "NM=/home/furutaka/work/gcc/gcc-10.3.0-bld/./gcc/nm" "NM_FOR_BUILD=" "NM_FOR_TARGET=nm" "DESTDIR=" "WERROR=" all-recursive
> make[8]: Entering directory '/home/furutaka/work/gcc/gcc-10.3.0-bld/x86_64-pc-linux-gnu/32/libstdc++-v3'
> Making all in include
> make[9]: Entering directory '/home/furutaka/work/gcc/gcc-10.3.0-bld/x86_64-pc-linux-gnu/32/libstdc++-v3/include'
> 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
>
>
> It seems to me that at some point of the build, for some
> reasons the already installed libstdc++ which contain
> GLIBCXX_3.4.29 was referenced or used in the currently
> building system...

Do you have LD_LIBRARY_PATH or LD_RUN_PATH set in your environment?

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problem building older versions of gcc
  2021-06-04 14:20 ` Jonathan Wakely
@ 2021-06-04 14:26   ` Kazuyoshi Furutaka
  0 siblings, 0 replies; 14+ messages in thread
From: Kazuyoshi Furutaka @ 2021-06-04 14:26 UTC (permalink / raw)
  To: jwakely.gcc; +Cc: gcc-help

From: Jonathan Wakely <jwakely.gcc@gmail.com>
Subject: Re: Problem building older versions of gcc
Date: Fri, 4 Jun 2021 15:20:16 +0100

> Do you have LD_LIBRARY_PATH or LD_RUN_PATH set in your environment?

No.

[furutaka@peart-furu-or-jp gcc-10.3.0-bld]$ printenv | grep LD_
DYLD_LIBRARY_PATH=/usr/local/root/lib
LD_LIBRARY_PATH_modshare=/usr/lib64/mpich/lib:1
MODULES_RUN_QUARANTINE=LD_LIBRARY_PATH LD_PRELOAD

Kazuyoshi
--
Kazuyoshi Furutaka
furutaka@jb3.so-net.ne.jp

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problem building older versions of gcc
  2021-06-04 13:30 Problem building older versions of gcc Kazuyoshi Furutaka
  2021-06-04 14:20 ` Jonathan Wakely
@ 2021-06-12  7:37 ` Kazuyoshi Furutaka
  2021-06-12  8:06   ` Xi Ruoyao
  1 sibling, 1 reply; 14+ messages in thread
From: Kazuyoshi Furutaka @ 2021-06-12  7:37 UTC (permalink / raw)
  To: gcc-help

Any suggestions?

Kazuyoshi

From: Kazuyoshi Furutaka via Gcc-help <gcc-help@gcc.gnu.org>
Subject: Problem building older versions of gcc
Date: Fri, 04 Jun 2021 22:30:51 +0900 (JST)

> Dear experts...
> 
> I'm having troubles building GCC 10.3.0 (and a few
> older versions) with the newer one.
> 
> The system is Fedora release 34 (Thirty Four), x86_64.
> The installed gcc version is:
>   gcc (GCC) 11.1.1 20210428 (Red Hat 11.1.1-1)
> 
> I downloaded gcc-10.3.0.tar.xz and expand it, and then
> did
>   `../gcc-10.3.0/configure --prefix=/usr/local/gcc/10.3.0`
> from another directory, and `make`.
> 
> The make failed as the following (the same occured for
> 10.2.0, 10.1.0, and 9.4.0).
> 
> ...
> make[7]: Entering directory '/home/furutaka/work/gcc/gcc-10.3.0-bld/x86_64-pc-linux-gnu/32/libstdc++-v3'
> make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CC_FOR_TARGET=/home/furutaka/work/gcc/gcc-10.3.0-bld/./gcc/xgcc -B/home/furutaka/work/gcc/gcc-10.3.0-bld/./gcc/" "CFLAGS=-g -O2  -m32" "CXXFLAGS=-g -O2 -D_GNU_SOURCE  -m32" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g -O2" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS=-m32" "LIBCFLAGS=-g -O2  -m32" "LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=make" "MAKEINFO=makeinfo --split-size=5000000 --split-size=5000000 --split-size=5000000     " "SHELL=/bin/sh" "RUNTESTFLAGS=" "exec_prefix=/usr/local/gcc/10.3.0" "infodir=/usr/local/gcc/10.3.0/share/info" "libdir=/usr/local/gcc/10.3.0/lib" "includedir=/usr/local/gcc/10.3.0/include" "prefix=/usr/local/gcc/10.3.0" "tooldir=/usr/local/gcc/10.3.0/x86_64-pc-linux-gnu" "gxx_include_dir=/usr/local/gcc/10.3.0/include/c++/10.3.0" "AR=ar" "AS=/home/furutaka/work/gcc/gcc-10.3.0-bld/./gcc/as" "LD=/home/furutaka/work/gcc/gcc-10.3.0-bld/./gcc/collect-ld" "RANLIB=ranlib" "NM=/home/furutaka/work/gcc/gcc-10.3.0-bld/./gcc/nm" "NM_FOR_BUILD=" "NM_FOR_TARGET=nm" "DESTDIR=" "WERROR=" all-recursive
> make[8]: Entering directory '/home/furutaka/work/gcc/gcc-10.3.0-bld/x86_64-pc-linux-gnu/32/libstdc++-v3'
> Making all in include
> make[9]: Entering directory '/home/furutaka/work/gcc/gcc-10.3.0-bld/x86_64-pc-linux-gnu/32/libstdc++-v3/include'
> 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
> 
> 
> It seems to me that at some point of the build, for some
> reasons the already installed libstdc++ which contain
> GLIBCXX_3.4.29 was referenced or used in the currently
> building system...
> 
> 
> [furutaka@peart-furu-or-jp gcc-10.3.0-bld]$ strings /home/furutaka/work/gcc/gcc-10.3.0-bld/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6 | grep "^GLIBCXX_3.4.2." | sort | uniq
> GLIBCXX_3.4.20
> GLIBCXX_3.4.21
> GLIBCXX_3.4.22
> GLIBCXX_3.4.23
> GLIBCXX_3.4.24
> GLIBCXX_3.4.25
> GLIBCXX_3.4.26
> GLIBCXX_3.4.27
> GLIBCXX_3.4.28
> 
> [furutaka@peart-furu-or-jp gcc-10.3.0-bld]$ strings /lib64/libstdc++.so.6 | grep "^GLIBCXX_3.4.2." | sort | uniq
> GLIBCXX_3.4.20
> GLIBCXX_3.4.21
> GLIBCXX_3.4.22
> GLIBCXX_3.4.23
> GLIBCXX_3.4.24
> GLIBCXX_3.4.25
> GLIBCXX_3.4.26
> GLIBCXX_3.4.27
> GLIBCXX_3.4.28
> GLIBCXX_3.4.29
> 
> How do I fix this?
> 
> Thanks in advance...
> 
> Kazuyoshi
> --
> Kazuyoshi Furutaka
> furutaka@jb3.so-net.ne.jp

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problem building older versions of gcc
  2021-06-12  7:37 ` Kazuyoshi Furutaka
@ 2021-06-12  8:06   ` Xi Ruoyao
  2021-06-12 10:39     ` Kazuyoshi Furutaka
  0 siblings, 1 reply; 14+ messages in thread
From: Xi Ruoyao @ 2021-06-12  8:06 UTC (permalink / raw)
  To: Kazuyoshi Furutaka; +Cc: gcc-help

On Sat, 2021-06-12 at 16:37 +0900, Kazuyoshi Furutaka via Gcc-help
wrote:
> Any suggestions?
> 
> Kazuyoshi
> 
> From: Kazuyoshi Furutaka via Gcc-help <gcc-help@gcc.gnu.org>
> Subject: Problem building older versions of gcc
> Date: Fri, 04 Jun 2021 22:30:51 +0900 (JST)
> > It seems to me that at some point of the build, for some
> 
> > reasons the already installed libstdc++ which contain
> 
> > GLIBCXX_3.4.29 was referenced or used in the currently
> 
> > building system...

cc1plus shouldn't link to libstdc++.so.  Instead it links to static
library libstdc++.a (at least by default).

Did you override --with-stage1-libs in configure command line?
-- 
Xi Ruoyao <xry111@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problem building older versions of gcc
  2021-06-12  8:06   ` Xi Ruoyao
@ 2021-06-12 10:39     ` Kazuyoshi Furutaka
  2021-06-14 21:12       ` Jim Wilson
  0 siblings, 1 reply; 14+ messages in thread
From: Kazuyoshi Furutaka @ 2021-06-12 10:39 UTC (permalink / raw)
  To: gcc-help, xry111

From: Xi Ruoyao <xry111@mengyan1223.wang>
Subject: Re: Problem building older versions of gcc
Date: Sat, 12 Jun 2021 16:06:04 +0800

> On Sat, 2021-06-12 at 16:37 +0900, Kazuyoshi Furutaka via Gcc-help
> wrote:
>> Any suggestions?
>> 
>> Kazuyoshi
>> 
>> From: Kazuyoshi Furutaka via Gcc-help <gcc-help@gcc.gnu.org>
>> Subject: Problem building older versions of gcc
>> Date: Fri, 04 Jun 2021 22:30:51 +0900 (JST)
>> > It seems to me that at some point of the build, for some
>> 
>> > reasons the already installed libstdc++ which contain
>> 
>> > GLIBCXX_3.4.29 was referenced or used in the currently
>> 
>> > building system...
> 
> cc1plus shouldn't link to libstdc++.so.  Instead it links to static
> library libstdc++.a (at least by default).

Yes, I think so.

> Did you override --with-stage1-libs in configure command line?

No, absolutely...

Kazuyoshi

From: Kazuyoshi Furutaka via Gcc-help <gcc-help@gcc.gnu.org>
Subject: Problem building older versions of gcc
Date: Fri, 04 Jun 2021 22:30:51 +0900 (JST)

> I downloaded gcc-10.3.0.tar.xz and expand it, and then
> did
>   `../gcc-10.3.0/configure --prefix=/usr/local/gcc/10.3.0`
> from another directory, and `make`.
--
Kazuyoshi Furutaka
furutaka@jb3.so-net.ne.jp

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problem building older versions of gcc
  2021-06-12 10:39     ` Kazuyoshi Furutaka
@ 2021-06-14 21:12       ` Jim Wilson
  2021-06-19  2:45         ` Kazuyoshi Furutaka
  0 siblings, 1 reply; 14+ messages in thread
From: Jim Wilson @ 2021-06-14 21:12 UTC (permalink / raw)
  To: Kazuyoshi Furutaka; +Cc: gcc-help, xry111

On Sat, Jun 12, 2021 at 3:39 AM Kazuyoshi Furutaka via Gcc-help <
gcc-help@gcc.gnu.org> 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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problem building older versions of gcc
  2021-06-14 21:12       ` Jim Wilson
@ 2021-06-19  2:45         ` Kazuyoshi Furutaka
  2021-06-19  4:26           ` Xi Ruoyao
  0 siblings, 1 reply; 14+ messages in thread
From: Kazuyoshi Furutaka @ 2021-06-19  2:45 UTC (permalink / raw)
  To: gcc-help

Hi all...

From: Jim Wilson <jimw@sifive.com>
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@gcc.gnu.org> 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@gcc.gnu.org>
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)"

What can be the cause of the difference???

Thanks.

Kazuyoshi
--
Kazuyoshi Furutaka
furutaka@jb3.so-net.ne.jp

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problem building older versions of gcc
  2021-06-19  2:45         ` Kazuyoshi Furutaka
@ 2021-06-19  4:26           ` Xi Ruoyao
  2021-06-19  4:29             ` Xi Ruoyao
  0 siblings, 1 reply; 14+ messages in thread
From: Xi Ruoyao @ 2021-06-19  4:26 UTC (permalink / raw)
  To: Kazuyoshi Furutaka, gcc-help

On Sat, 2021-06-19 at 11:45 +0900, Kazuyoshi Furutaka via Gcc-help
wrote:
> Hi all...
> 
> From: Jim Wilson <jimw@sifive.com>
> 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@gcc.gnu.org> 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@gcc.gnu.org>
> 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@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problem building older versions of gcc
  2021-06-19  4:26           ` Xi Ruoyao
@ 2021-06-19  4:29             ` Xi Ruoyao
  2021-06-19  7:12               ` Kazuyoshi Furutaka
  0 siblings, 1 reply; 14+ messages in thread
From: Xi Ruoyao @ 2021-06-19  4:29 UTC (permalink / raw)
  To: Kazuyoshi Furutaka, gcc-help

On Sat, 2021-06-19 at 12:26 +0800, Xi Ruoyao via Gcc-help wrote:

> 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.

A quick search confirmed my guess:

https://fedora.pkgs.org/34/fedora-x86_64/libstdc++-static-11.0.1-0.3.fc34.x86_64.rpm.html
-- 
Xi Ruoyao <xry111@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problem building older versions of gcc
  2021-06-19  4:29             ` Xi Ruoyao
@ 2021-06-19  7:12               ` Kazuyoshi Furutaka
  2021-06-19  7:28                 ` Xi Ruoyao
  0 siblings, 1 reply; 14+ messages in thread
From: Kazuyoshi Furutaka @ 2021-06-19  7:12 UTC (permalink / raw)
  To: gcc-help

Dear Xi Ruoyao, thanks for your suggestion.

From: Xi Ruoyao <xry111@mengyan1223.wang>
Subject: Re: Problem building older versions of gcc
Date: Sat, 19 Jun 2021 12:26:38 +0800

> 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.

In the Fedora-33 testing system on QEMU/KVM (with gcc-10.3.1 installed),
I've also tried the builds of gcc-9.4.0 and gcc-8.5.0, and the builds ended
successfully. (by the way, the versions of libstdc++ are the same, 6.0.29,
on both testing Fedora-33 and Fedora-34 systems)


From: Xi Ruoyao <xry111@mengyan1223.wang>
Subject: Re: Problem building older versions of gcc
Date: Sat, 19 Jun 2021 12:29:19 +0800

> On Sat, 2021-06-19 at 12:26 +0800, Xi Ruoyao via Gcc-help wrote:
> 
>> 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.
> 
> A quick search confirmed my guess:
> 
> https://fedora.pkgs.org/34/fedora-x86_64/libstdc++-static-11.0.1-0.3.fc34.x86_64.rpm.html

I'm sorry but what are your points?

Indeed, as I mentioned in the previous post, in Fedora there's
a separate package for static libstdc++ library, and as I wrote,
only after installing it, the build with simple (--prefix only)
configuration succeeded on a Fedora-34 system.

And, the cc1plus installed in Fedora-34 does not depend on
the system's libstdc++:

> [furutaka@peart-furu-or-jp gcc]$ rpm -ql gcc-c++|grep cc1plus
> /usr/libexec/gcc/x86_64-redhat-linux/11/cc1plus
> [furutaka@peart-furu-or-jp gcc]$ ldd /usr/libexec/gcc/x86_64-redhat-linux/11/cc1plus
>       linux-vdso.so.1 (0x00007ffd00acc000)
>       libdl.so.2 => /lib64/libdl.so.2 (0x0000153c91528000)
>       libmpc.so.3 => /lib64/libmpc.so.3 (0x0000153c91508000)
>       libmpfr.so.6 => /lib64/libmpfr.so.6 (0x0000153c91458000)
>       libgmp.so.10 => /lib64/libgmp.so.10 (0x0000153c913b0000)
>       libz.so.1 => /lib64/libz.so.1 (0x0000153c91390000)
>       libzstd.so.1 => /lib64/libzstd.so.1 (0x0000153c91298000)
>       libm.so.6 => /lib64/libm.so.6 (0x0000153c91150000)
>       libc.so.6 => /lib64/libc.so.6 (0x0000153c90f80000)
>       /lib64/ld-linux-x86-64.so.2 (0x0000153c91568000)
>       libpthread.so.0 => /lib64/libpthread.so.0 (0x0000153c90f58000)

On the other hand, the stage-1 cc1plus is built in advance
to libstdc++.so, and therefore I think it's inevitable that
the stage-1 cc1plus depends on the system's libstdc++.so
(or else the stage-1 cc1plus should be statically linked).

So...

> 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.

I think that the newly built stage-1 cc1plus CAN NOT use
for itself the new libstdc++.so.6 because it does NOT exist.
By the way, LD_LIbRARY_PATH is not defined on both F33 & F34 systems.


So, I'm still wondering the cause of the differences between
the two systems.

Kazuyoshi
--
Kazuyoshi Furutaka
furutaka@jb3.so-net.ne.jp

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problem building older versions of gcc
  2021-06-19  7:12               ` Kazuyoshi Furutaka
@ 2021-06-19  7:28                 ` Xi Ruoyao
  2021-06-19  8:19                   ` Kazuyoshi Furutaka
  0 siblings, 1 reply; 14+ messages in thread
From: Xi Ruoyao @ 2021-06-19  7:28 UTC (permalink / raw)
  To: Kazuyoshi Furutaka, gcc-help

On Sat, 2021-06-19 at 16:12 +0900, Kazuyoshi Furutaka via Gcc-help
wrote:
> Dear Xi Ruoyao, thanks for your suggestion.
> 
> From: Xi Ruoyao <xry111@mengyan1223.wang>
> Subject: Re: Problem building older versions of gcc
> Date: Sat, 19 Jun 2021 12:26:38 +0800
> 
> > 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.
> 
> In the Fedora-33 testing system on QEMU/KVM (with gcc-10.3.1 installed),
> I've also tried the builds of gcc-9.4.0 and gcc-8.5.0, and the builds
> ended
> successfully. (by the way, the versions of libstdc++ are the same,
> 6.0.29,
> on both testing Fedora-33 and Fedora-34 systems)
> 
> 
> From: Xi Ruoyao <xry111@mengyan1223.wang>
> Subject: Re: Problem building older versions of gcc
> Date: Sat, 19 Jun 2021 12:29:19 +0800
> 
> > On Sat, 2021-06-19 at 12:26 +0800, Xi Ruoyao via Gcc-help wrote:
> > 
> > > 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.
> > 
> > A quick search confirmed my guess:
> > 
> > https://fedora.pkgs.org/34/fedora-x86_64/libstdc++-static-11.0.1-0.3.fc34.x86_64.rpm.html
> 
> I'm sorry but what are your points?
> 
> Indeed, as I mentioned in the previous post, in Fedora there's
> a separate package for static libstdc++ library, and as I wrote,
> only after installing it, the build with simple (--prefix only)
> configuration succeeded on a Fedora-34 system.
> 
> And, the cc1plus installed in Fedora-34 does not depend on
> the system's libstdc++:
> 
> > [furutaka@peart-furu-or-jp gcc]$ rpm -ql gcc-c++|grep cc1plus
> > /usr/libexec/gcc/x86_64-redhat-linux/11/cc1plus
> > [furutaka@peart-furu-or-jp gcc]$ ldd /usr/libexec/gcc/x86_64-redhat-
> > linux/11/cc1plus
> >        linux-vdso.so.1 (0x00007ffd00acc000)
> >        libdl.so.2 => /lib64/libdl.so.2 (0x0000153c91528000)
> >        libmpc.so.3 => /lib64/libmpc.so.3 (0x0000153c91508000)
> >        libmpfr.so.6 => /lib64/libmpfr.so.6 (0x0000153c91458000)
> >        libgmp.so.10 => /lib64/libgmp.so.10 (0x0000153c913b0000)
> >        libz.so.1 => /lib64/libz.so.1 (0x0000153c91390000)
> >        libzstd.so.1 => /lib64/libzstd.so.1 (0x0000153c91298000)
> >        libm.so.6 => /lib64/libm.so.6 (0x0000153c91150000)
> >        libc.so.6 => /lib64/libc.so.6 (0x0000153c90f80000)
> >        /lib64/ld-linux-x86-64.so.2 (0x0000153c91568000)
> >        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000153c90f58000)
> 
> On the other hand, the stage-1 cc1plus is built in advance
> to libstdc++.so, and therefore I think it's inevitable that
> the stage-1 cc1plus depends on the system's libstdc++.so
> (or else the stage-1 cc1plus should be statically linked).
> 
> So...
> 
> > 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.


> I think that the newly built stage-1 cc1plus CAN NOT use
> for itself the new libstdc++.so.6 because it does NOT exist.

From your log, it can be seen it's already built:

> /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)

x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6 is there.

> By the way, LD_LIbRARY_PATH is not defined on both F33 & F34 systems.

It's not F33 or F34 sets LD_LIBRARY_PATH, it's GCC building system
setting it.

> So, I'm still wondering the cause of the differences between
> the two systems.

Fedora 33 is using GCC 10, which matches the GCC version you are
building.

When libstdc++.a is not installed, stage 1 cc1plus etc. links to system
libstdc++.so.

GCC building system (automatically) sets LD_LIBRARY_PATH to contain
newly built runtime libraries.  So a newly built libstdc++.so is found
anyway.

On Fedora 33 system the libstdc++.so built in stage 1 is compatible with
system one.  On Fedora 34 it's not.
-- 
Xi Ruoyao <xry111@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problem building older versions of gcc
  2021-06-19  7:28                 ` Xi Ruoyao
@ 2021-06-19  8:19                   ` Kazuyoshi Furutaka
  2021-06-19  8:31                     ` Xi Ruoyao
  0 siblings, 1 reply; 14+ messages in thread
From: Kazuyoshi Furutaka @ 2021-06-19  8:19 UTC (permalink / raw)
  To: gcc-help

Dear Xi Ruoyao, thanks again.

From: Xi Ruoyao <xry111@mengyan1223.wang>
Subject: Re: Problem building older versions of gcc
Date: Sat, 19 Jun 2021 15:28:16 +0800

>> I think that the newly built stage-1 cc1plus CAN NOT use
>> for itself the new libstdc++.so.6 because it does NOT exist.
> 
> From your log, it can be seen it's already built:

I said that libstdc++.so.6 was NOT THERE WHEN cc1plus WAS BUILT,
and the newly built cc1plus should depend on the system's.


>> /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)
> 
> x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6 is there.

You pointed at the error occured, where the newly built
cc1plus was USED, and the newly built libstdc++.so.6
was used to build
  "-o x86_64-pc-linux-gnu/bits/stdc++.h.gch/O2g.gch"
or something like that.


>> By the way, LD_LIbRARY_PATH is not defined on both F33 & F34 systems.
> 
> It's not F33 or F34 sets LD_LIBRARY_PATH, it's GCC building system
> setting it.
>
>> So, I'm still wondering the cause of the differences between
>> the two systems.
> 
> Fedora 33 is using GCC 10, which matches the GCC version you are
> building.

What about the success of gcc-9.4.0 and gcc-8.5.0 builds?

> When libstdc++.a is not installed, stage 1 cc1plus etc. links to system
> libstdc++.so.
> 
> GCC building system (automatically) sets LD_LIBRARY_PATH to contain
> newly built runtime libraries.  So a newly built libstdc++.so is found
> anyway.
> 
> On Fedora 33 system the libstdc++.so built in stage 1 is compatible with
> system one.  On Fedora 34 it's not.

It may be so for the gcc-10.3.0 build, but for gcc-8.5.0 build,

> [furutaka@localhost gcc-8.5.0-bld]$ strings /lib64/libstdc++.so.6 | grep "^GLIBCXX_3.4.2" | sort | uniq
> GLIBCXX_3.4.2
> GLIBCXX_3.4.20
> GLIBCXX_3.4.21
> GLIBCXX_3.4.22
> GLIBCXX_3.4.23
> GLIBCXX_3.4.24
> GLIBCXX_3.4.25
> GLIBCXX_3.4.26
> GLIBCXX_3.4.27
> GLIBCXX_3.4.28
> [furutaka@localhost gcc-8.5.0-bld]$ strings ./stage1-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6 | grep "^GLIBCXX_3.4.2" | sort | uniq
> GLIBCXX_3.4.2
> GLIBCXX_3.4.20
> GLIBCXX_3.4.21
> GLIBCXX_3.4.22
> GLIBCXX_3.4.23
> GLIBCXX_3.4.24
> GLIBCXX_3.4.25

that is, I think the newly built library do not have
at least a few symbols that the sytem library have.
Can we think they are still compatible?

Could you be kind enought to point me to some good web
pages or books in/on which GCC's 3-stage building processes
and how the linker works?

Thanks,

Kazuyoshi
--
Kazuyoshi Furutaka
furutaka@jb3.so-net.ne.jp

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problem building older versions of gcc
  2021-06-19  8:19                   ` Kazuyoshi Furutaka
@ 2021-06-19  8:31                     ` Xi Ruoyao
  0 siblings, 0 replies; 14+ messages in thread
From: Xi Ruoyao @ 2021-06-19  8:31 UTC (permalink / raw)
  To: Kazuyoshi Furutaka, gcc-help

On Sat, 2021-06-19 at 17:19 +0900, Kazuyoshi Furutaka via Gcc-help
wrote:
> Dear Xi Ruoyao, thanks again.
> 
> From: Xi Ruoyao <xry111@mengyan1223.wang>
> Subject: Re: Problem building older versions of gcc
> Date: Sat, 19 Jun 2021 15:28:16 +0800
> 
> > > I think that the newly built stage-1 cc1plus CAN NOT use
> > > for itself the new libstdc++.so.6 because it does NOT exist.
> > 
> > From your log, it can be seen it's already built:
> 
> I said that libstdc++.so.6 was NOT THERE WHEN cc1plus WAS BUILT,
> and the newly built cc1plus should depend on the system's.
> 
> 
> > > /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)
> > 
> > x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6 is there.
> 
> You pointed at the error occured, where the newly built
> cc1plus was USED, and the newly built libstdc++.so.6
> was used to build
>   "-o x86_64-pc-linux-gnu/bits/stdc++.h.gch/O2g.gch"
> or something like that.

Correct.

> 
> > > By the way, LD_LIbRARY_PATH is not defined on both F33 & F34
> > > systems.
> > 
> > It's not F33 or F34 sets LD_LIBRARY_PATH, it's GCC building system
> > setting it.
> > 
> > > So, I'm still wondering the cause of the differences between
> > > the two systems.
> > 
> > Fedora 33 is using GCC 10, which matches the GCC version you are
> > building.
> 
> What about the success of gcc-9.4.0 and gcc-8.5.0 builds?

Perhaps, they didn't use those symbols with higher version.

> > When libstdc++.a is not installed, stage 1 cc1plus etc. links to
> > system
> > libstdc++.so.
> > 
> > GCC building system (automatically) sets LD_LIBRARY_PATH to contain
> > newly built runtime libraries.  So a newly built libstdc++.so is
> > found
> > anyway.
> > 
> > On Fedora 33 system the libstdc++.so built in stage 1 is compatible
> > with
> > system one.  On Fedora 34 it's not.
> 
> It may be so for the gcc-10.3.0 build, but for gcc-8.5.0 build,
> 
> > [furutaka@localhost gcc-8.5.0-bld]$ strings /lib64/libstdc++.so.6 |
> > grep "^GLIBCXX_3.4.2" | sort | uniq
> > GLIBCXX_3.4.2
> > GLIBCXX_3.4.20
> > GLIBCXX_3.4.21
> > GLIBCXX_3.4.22
> > GLIBCXX_3.4.23
> > GLIBCXX_3.4.24
> > GLIBCXX_3.4.25
> > GLIBCXX_3.4.26
> > GLIBCXX_3.4.27
> > GLIBCXX_3.4.28
> > [furutaka@localhost gcc-8.5.0-bld]$ strings ./stage1-x86_64-pc-
> > linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6 | grep
> > "^GLIBCXX_3.4.2" | sort | uniq
> > GLIBCXX_3.4.2
> > GLIBCXX_3.4.20
> > GLIBCXX_3.4.21
> > GLIBCXX_3.4.22
> > GLIBCXX_3.4.23
> > GLIBCXX_3.4.24
> > GLIBCXX_3.4.25
> 
> that is, I think the newly built library do not have
> at least a few symbols that the sytem library have.
> Can we think they are still compatible?

The system library (with more symbols) is compatible with the newly
built one.  But not vice versa.

If an executable (cc1plus, for example) uses some symbol with version
GLIBCXX_3.4.26, it won't run with newly built libstdc++.so.6 lacking
these symbols.  But if it does not use those symbols, it can run
normally.

-- 
Xi Ruoyao <xry111@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University


^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2021-06-19  8:31 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-04 13:30 Problem building older versions of gcc Kazuyoshi Furutaka
2021-06-04 14:20 ` Jonathan Wakely
2021-06-04 14:26   ` Kazuyoshi Furutaka
2021-06-12  7:37 ` Kazuyoshi Furutaka
2021-06-12  8:06   ` Xi Ruoyao
2021-06-12 10:39     ` Kazuyoshi Furutaka
2021-06-14 21:12       ` Jim Wilson
2021-06-19  2:45         ` Kazuyoshi Furutaka
2021-06-19  4:26           ` Xi Ruoyao
2021-06-19  4:29             ` Xi Ruoyao
2021-06-19  7:12               ` Kazuyoshi Furutaka
2021-06-19  7:28                 ` Xi Ruoyao
2021-06-19  8:19                   ` Kazuyoshi Furutaka
2021-06-19  8:31                     ` Xi Ruoyao

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).