Dear Xi Ruoyao, thanks for your suggestion. From: Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx
