On a RHEL7.6 system, bootstrapping consistently fails in stage3 for emerging gcc with the error: x86_64-pc-linux-gnu-g++: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /ws/sderoeck/gentoo/var/tmp/portage/sys-devel/gcc-9.2.0-r2/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6) When I compared the logs of this bootstrap with successful RHEL7.6 bootstraps (on another system), one of the differences I saw was that "configure" consistently reported that building "-static" fails. Because I have root rights on this system, I was able to do: yum install glibc-static libstdc++-static. Another bootstrap attempt then successfully emerges the stage3 gcc. But I guess prefix bootstrap shouldn't depend on this package being installed at all? Or even: this indicates an unexpected dependence of the completed stage2 on the host libc?
Created attachment 599054 [details] stage 3 log before installing glibc-static on host
Created attachment 599056 [details] stage 3 log after installing glibc-static on host
I reproduced the same issue on a Fedora 30 system. However I am not root on my system so I could not confirm that the proposed fix is working.
Although I'm not using the standalone Prefix variant but guest Prefix only, this problem seems to be that gcc is trying to link against /lib64/libc.so.6 while it actually should link against the prefix'ed one instead, given that sys-libs/glibc is merge some packages earlier.
I was asked (xdej) on #gentoo-prefix to change the status of this bug to confirmed but I do not have 'canconfirm' permissions. Stefaan or someone else can you change the status of the bug?
(In reply to Stefaan De Roeck from comment #0) > On a RHEL7.6 system, bootstrapping consistently fails in stage3 for emerging > gcc with the error: > > x86_64-pc-linux-gnu-g++: /lib64/libc.so.6: version `GLIBC_2.18' not found > (required by > /ws/sderoeck/gentoo/var/tmp/portage/sys-devel/gcc-9.2.0-r2/work/build/x86_64- > pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6) > > When I compared the logs of this bootstrap with successful RHEL7.6 > bootstraps (on another system), one of the differences I saw was that > "configure" consistently reported that building "-static" fails. > Because I have root rights on this system, I was able to do: yum install > glibc-static libstdc++-static. Another bootstrap attempt then successfully > emerges the stage3 gcc. > > But I guess prefix bootstrap shouldn't depend on this package being > installed at all? Or even: this indicates an unexpected dependence of the > completed stage2 on the host libc? Hi, could you please try again? Recently we have fixed a bug in binutils which might have caused this bug. https://bugs.gentoo.org/708184
(In reply to Benda Xu from comment #6) > Hi, could you please try again? Recently we have fixed a bug in binutils > which might have caused this bug. > > https://bugs.gentoo.org/708184 On Ubuntu 18.04 LTS, bootstrapping failed in stage 3 while emerging net-misc/wget with error: /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `__libc_vfork@GLIBC_PRIVATE'
(In reply to Ashwin A Kumar from comment #7) > (In reply to Benda Xu from comment #6) > > > Hi, could you please try again? Recently we have fixed a bug in binutils > > which might have caused this bug. > > > > https://bugs.gentoo.org/708184 > > On Ubuntu 18.04 LTS, bootstrapping failed in stage 3 while emerging > net-misc/wget with error: > > /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ > ld: /lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to > `__libc_vfork@GLIBC_PRIVATE' I am unable to upload the whole log file. Instead, i have last few links: http://ix.io/2eh8 => This was on my first try http://ix.io/2eiC => This was on my first try on another machine which has some additional errors
Exatcly the same failure as Ashwin A Kumar's here on MX-Linux 19.1 (functionally Debian Buster).
Also, a new error occurred while it was emering with openssh => ix.io/2et7
(In reply to Ashwin A Kumar from comment #10) > Also, a new error occurred while it was emering with openssh => ix.io/2et7 Edit : http://ix.io/2et7
(In reply to Ashwin A Kumar from comment #10) > Also, a new error occurred while it was emering with openssh => ix.io/2et7 No, only wget.
Created attachment 629250 [details, diff] Workaround that ovewrites host loader with prefix loader in stage2 gcc binaries Attached is a workaround patch, tested on CentOS with all 4 combinations 4 combinations of {libstdc++-static, glibc-static} installed/not-installed. Note: glibc-static makes no difference; the problem is with availability of libstdc++.a on the host. In summary, the problem is that for hosts that don't provide libstdc++.a, stage2 gcc is linked against host's libstdc++.so. On such hosts, -static-libstdc++ is NOT passed during the gcc build (nor would it make any sense to pass it, since the static library file does not exist), according to gcc documentation ( https://gcc.gnu.org/install/configure.html ): --with-stage1-ldflags=flags This option may be used to set linker flags to be used when linking stage 1 of GCC. These are also used when linking GCC if configured with --disable-bootstrap. If --with-stage1-libs is not set to a value, then the default is ‘-static-libstdc++ -static-libgcc’, *if supported*. So, stage2 gcc is dynamically linked against host's libstdc++.so. This stage2 gcc then fails to build stage 3 gcc for reasons detailed in the following section. As far as I can tell, the resolution for such hosts (which do really exist in the wild: OP's case, my case) is then either: A. fix the dynamically-linked stage2 gcc to still work for building stage3 gcc: attached patch is one successful attempt at doing this. B. link stage2 gcc statically, by either: B1. somehow provide libstdc++.a -- doesn't seem practical (fetching and extracting a binary distro package libstdc++-static would be distro-specific and fragile, and won't work if the user is using some custom gcc toolchain) B2. let stage2 gcc bootstrap itself (see --enable-bootstrap), which presumably involves building libstdc++.a and linking against it in the second phase. My attempt at this failed (see section below). C. other ideas? I don't know what the right approach is. B2 seems cleaner than A, and I'm not sure whether A is a robust fix and whether it works on other supported platforms. But, A was the only workaround that I could implement successfully (tested building prefix from scratch on CentOS with all 4 combinations of glib-static/libstdc++-static installed/not-installed). If this approach is taken, I might be able to help with testing on OS X and Windows. WHY DYNAMICALLY LINKED STAGE 2 GCC FAILS TO BUILD STAGE 3 GCC ------------------------------------------------------------- Prefix build is successful, when libstdc++.a is installed on the host, because the stage2 gcc is not dynamically linked against libstdc++.so: $ readelf -d gprefix-expat-gyes-syes-fail/tmp/usr/bin/x86_64-pc-linux-gnu-g++ Dynamic section at offset 0x10cde0 contains 27 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2] 0x000000000000000f (RPATH) Library rpath: [/home/acolin/gprefix-expat-gyes-syes-fail/tmp/usr/lib] $ ldd gprefix-expat-gyes-syes-fail/tmp/usr/bin/x86_64-pc-linux-gnu-g++ linux-vdso.so.1 => (0x00007ffc98ad6000) libm.so.6 => /lib64/libm.so.6 (0x00007fafa61dc000) libc.so.6 => /lib64/libc.so.6 (0x00007fafa5e0e000) /lib64/ld-linux-x86-64.so.2 (0x00007fafa64de000) When libstdc++.a is not installed on the host, prefix build fails during build of stage3 gcc, because stage2 gcc is dynamically linked against host's libstdc++.so, when stage2 gcc is invoked (to build stage3 gcc), it is invoked with an overriden LD_LIBRARY_PATH that points to stage3 gcc's freshly built libstdc++.so, which may be (is) incompatible with host's libc.so $ readelf -d gprefix-expat-gyes-sno-fail/tmp/usr/bin/x86_64-pc-linux-gnu-g++ Dynamic section at offset 0xf9dd0 contains 28 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000f (RPATH) Library rpath: [/home/acolin/gprefix-expat-gyes-sno-fail/tmp/usr/lib] $ readelf -l gprefix-expat-gyes-sno-fail/tmp/usr/bin/x86_64-pc-linux-gnu-g++ | grep -i interpreter [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] $ ldd gprefix-expat-gyes-sno-fail/tmp/usr/bin/x86_64-pc-linux-gnu-g++ linux-vdso.so.1 => (0x00007fff6b7e2000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007ff175f83000) libm.so.6 => /lib64/libm.so.6 (0x00007ff175c81000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ff175a6b000) libc.so.6 => /lib64/libc.so.6 (0x00007ff17569d000) /lib64/ld-linux-x86-64.so.2 (0x00007ff17628a000) $ gprefix-expat-gyes-sno-fail/usr/bin/ldd gprefix-expat-gyes-sno-fail/tmp/usr/bin/x86_64-pc-linux-gnu-g++ linux-vdso.so.1 (0x00007ffdacb1f000) libstdc++.so.6 => /home/acolin/gprefix-expat-gyes-sno-fail/tmp/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/libstdc++.so.6 (0x00007f96ce171000) libm.so.6 => /home/acolin/gprefix-expat-gyes-sno-fail/lib64/libm.so.6 (0x00007f96ce024000) libgcc_s.so.1 => /home/acolin/gprefix-expat-gyes-sno-fail/tmp/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/libgcc_s.so.1 (0x00007f96ce00a000) libc.so.6 => /home/acolin/gprefix-expat-gyes-sno-fail/lib64/libc.so.6 (0x00007f96cde36000) /lib64/ld-linux-x86-64.so.2 => /home/acolin/gprefix-expat-gyes-sno-fail/lib64/ld-linux-x86-64.so.2 (0x00007f96ce3f3000) During build of stage3 gcc, loader path is overriden to point to freshly built libstdc++.so, which expects the freshly built eprefix/lib64/libc.so, but is not compatible with host's libc.so; hence the invocation of this stage2 gcc during build of stage3 gcc fails with this error: $ LD_LIBRARY_PATH=$PWD/gprefix-expat-gyes-sno-fail/var/tmp/portage/sys-devel/gcc-9.2.0-r3/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs gprefix-expat-gyes-sno-fail/tmp/usr/bin/x86_64-pc-linux-gnu-g++ --version gprefix-expat-gyes-sno-fail/tmp/usr/bin/x86_64-pc-linux-gnu-g++: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /home/acolin/gprefix-expat-gyes-sno-fail/var/tmp/portage/sys-devel/gcc-9.2.0-r3/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6) Loading through ldd shows the mismatch between libc and libstdc++: $ LD_LIBRARY_PATH=$PWD/gprefix-expat-gyes-sno-fail/var/tmp/portage/sys-devel/gcc-9.2.0-r3/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs ldd gprefix-expat-gyes-sno-fail/tmp/usr/bin/x86_64-pc-linux-gnu-g++ gprefix-expat-gyes-sno-fail/tmp/usr/bin/x86_64-pc-linux-gnu-g++: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /home/acolin/gprefix-expat-gyes-sno-fail/var/tmp/portage/sys-devel/gcc-9.2.0-r3/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6) linux-vdso.so.1 => (0x00007ffd129b0000) libstdc++.so.6 => /home/acolin/gprefix-expat-gyes-sno-fail/var/tmp/portage/sys-devel/gcc-9.2.0-r3/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6 (0x00007f107f47d000) libm.so.6 => /lib64/libm.so.6 (0x00007f107f17b000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f107ef65000) libc.so.6 => /lib64/libc.so.6 (0x00007f107eb97000) /lib64/ld-linux-x86-64.so.2 (0x00007f107f6f2000) But, things do work if the prefix's (not host's) loader is used: $ LD_LIBRARY_PATH=$PWD/gprefix-expat-gyes-sno-fail/var/tmp/portage/sys-devel/gcc-9.2.0-r3/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs gprefix-expat-gyes-sno-fail/usr/bin/ldd gprefix-expat-gyes-sno-fail/tmp/usr/bin/x86_64-pc-linux-gnu-g++ linux-vdso.so.1 (0x00007ffdcadfe000) libstdc++.so.6 => /home/acolin/gprefix-expat-gyes-sno-fail/var/tmp/portage/sys-devel/gcc-9.2.0-r3/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6 (0x00007f4d23a69000) libm.so.6 => /home/acolin/gprefix-expat-gyes-sno-fail/lib64/libm.so.6 (0x00007f4d23919000) libgcc_s.so.1 => /home/acolin/gprefix-expat-gyes-sno-fail/tmp/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/libgcc_s.so.1 (0x00007f4d238ff000) libc.so.6 => /home/acolin/gprefix-expat-gyes-sno-fail/lib64/libc.so.6 (0x00007f4d2372b000) /lib64/ld-linux-x86-64.so.2 => /home/acolin/gprefix-expat-gyes-sno-fail/lib64/ld-linux-x86-64.so.2 (0x00007f4d23ce0000) So, the attached patch overwrites the loader to the prefix's loader, like so: $ patchelf --set-interpreter $HOME/gprefix-expat-gyes-sno-fail/lib64/ld-linux-x86-64.so.2 gprefix-expat-gyes-sno-fail/tmp/usr/bin/x86_64-pc-linux-gnu-g++ Which fixes the issue: $ LD_LIBRARY_PATH=$PWD/gprefix-expat-gyes-sno-fail/var/tmp/portage/sys-devel/gcc-9.2.0-r3/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs gprefix-expat-gyes-sno-fail/tmp/usr/bin/x86_64-pc-linux-gnu-g++ --version x86_64-pc-linux-gnu-g++ (Gentoo 9.2.0-r3 p4) 9.2.0 FAILED ATTEMPT AT ALTERNATIVE FIX (BOOTSTRAPED STAGE2 GCC) ---------------------------------------------------------- I tried an alternative fix: enable bootstrap (by dropping --disable-bootstrap from gcc stage2 emerge). This attempt failed for two reasons. First, -lmpc and -lmpfr were not found while linking second gcc of stage2 gcc cc1plus; to resolve that I added --with-boot-ldflags=-L$ROOT/tmp/usr/lib (caveat: these libraries existed at time I looked; but I didn't do a from-scatch test so not sure if they are indeed built before stage2 gcc is linked). Second, gcc stage2 build failed when invoking a tool (genmddeps) on the build host. This tool was linked against libstdc++.so built during the stage2 gcc build, which (I'm guessing) is not compatible with the host's libstdc++.so; however, when this genmddeps tool is invoked, loader path is not overriden, so it tries to load host's libstdc++.so and fails: /home/acolin/gprefix-expat-gno-sno-bootstrap/tmp/var/tmp/portage/sys-devel/gcc-9.2.0-r3/work/build/./prev-gcc/xg++ ... \ -L/home/acolin/gprefix-expat-gno-sno-bootstrap/tmp/var/tmp/portage/sys-devel/gcc-9.2.0-r3/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs ... -L/home/acolin/gprefix-expat-gno-sno-bootstrap/tmp/usr/lib -no-pie -o build/genmddeps ... $ readelf -d gprefix-expat-gno-sno-bootstrap/tmp/var/tmp/portage/sys-devel/gcc-9.2.0-r3/work/build/gcc/build/genmddeps Dynamic section at offset 0x9dd8 contains 28 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] $ nm gprefix-expat-gno-sno-bootstrap/tmp/var/tmp/portage/sys-devel/gcc-9.2.0-r3/work/build/gcc/build/genmddeps | grep CXXABI_1.3.9 U _ZdlPvm@@CXXABI_1.3.9 $ nm /home/acolin/gprefix-expat-gno-sno-bootstrap/tmp/var/tmp/portage/sys-devel/gcc-9.2.0-r3/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6 | grep CXXABI_1.3.9 0000000000000000 A CXXABI_1.3.9 $ nm /lib64/libstdc++.so.6 | grep CXXABI_1.3.9 nm: /lib64/libstdc++.so.6: no symbols From failing build log: build/genmddeps ... > tmp-mddeps build/genmddeps: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by build/genmddeps) This issue with the build-host tools is fairly clear, but I don't see a way to resolve it.
not sure about this, bootstraps work on RAP and prefix guest
Did you happen to test on CentOS 7 host without libstdc++-static installed? I can re-test if you haven't.
I tried 8, but please retry on stock 7. We do need a c++ compiler to bootstrap though.
Confirmed obsolete. Can't reproduce anymore on the same CentOS 7.8.2003, libstdc++-static not installed, glibc-static not installed. Full bootstrap-prefix.sh completes all stages. Got fixed somewhere, maybe in GCC itself.
