On Sat, 2021-06-19 at 17:19 +0900, Kazuyoshi Furutaka via Gcc-help wrote: > Dear Xi Ruoyao, thanks again. > > From: Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx> > 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@xxxxxxxxxxxxxxxx> School of Aerospace Science and Technology, Xidian University
