From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mengyan1223.wang (mengyan1223.wang [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id A51693886C4C for ; Sat, 19 Jun 2021 08:31:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A51693886C4C Received: from [IPv6:240e:35a:1006:1c00:dc73:854d:832e:3] (unknown [IPv6:240e:35a:1006:1c00:dc73:854d:832e:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@mengyan1223.wang) by mengyan1223.wang (Postfix) with ESMTPSA id 07ADD65AFA; Sat, 19 Jun 2021 04:31:27 -0400 (EDT) Message-ID: Subject: Re: Problem building older versions of gcc From: Xi Ruoyao To: Kazuyoshi Furutaka , gcc-help@gcc.gnu.org Date: Sat, 19 Jun 2021 16:31:21 +0800 In-Reply-To: <20210619.171903.1457015790828756011.furutaka@jb3.so-net.ne.jp> References: <20210619.161239.1673187580808674509.furutaka@jb3.so-net.ne.jp> <9fd97ae5eb1b9a35bec1b8961fe962fa09fb2912.camel@mengyan1223.wang> <20210619.171903.1457015790828756011.furutaka@jb3.so-net.ne.jp> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3032.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2021 08:31:33 -0000 On Sat, 2021-06-19 at 17:19 +0900, Kazuyoshi Furutaka via Gcc-help wrote: > Dear Xi Ruoyao, thanks again. > > From: Xi Ruoyao > 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 School of Aerospace Science and Technology, Xidian University