From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16]) by sourceware.org (Postfix) with ESMTPS id B2E243858C60 for ; Mon, 13 Sep 2021 14:06:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B2E243858C60 Date: Mon, 13 Sep 2021 14:06:01 +0000 To: Xi Ruoyao , gcc-help@gcc.gnu.org From: Anthony de Almeida Lopes Reply-To: Anthony de Almeida Lopes Subject: Re: Building a host-isolated gcc without faking cross-compiling Message-ID: In-Reply-To: <494c39c9462eaf036e04aa7ede61325585af4da6.camel@mengyan1223.wang> References: <86a5dbe8-28c1-3113-b585-4e195c3f6534@gmail.com> <97c0acc2-5be0-30f3-6f2f-4b60eef95cb9@falsifiable.net> <1f4faf06-24ab-886b-d3db-a5fac2b34c15@gmail.com> <452e4e21-7dd8-5102-3fd2-dda12abde50d@falsifiable.net> <494c39c9462eaf036e04aa7ede61325585af4da6.camel@mengyan1223.wang> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Mon, 13 Sep 2021 14:06:14 -0000 Alright, fair enough, I surrender. I did end up solving the GCC_NO_EXECUTABLE in a better way by just including zlib in the source tree. I found the solution in this[1] bug report from libdragon. Then the reason things were crashing was my own fault: I incorrectly assumed setting LD_LIBRARY_PATH would set the dynamic linker but it doesn't do that. Running programs directly with the dynamic linker (like `usr/lib/ld-linux-x86-64.so.2 usr/bin/ls`) works fine. 1. https://github.com/DragonMinded/libdragon/issues/22 - Anthony On 9/11/21 10:32 AM, Xi Ruoyao wrote: > On Sat, 2021-09-11 at 04:55 +0000, Anthony de Almeida Lopes via Gcc-help > wrote: >> Alright, progress. I'm still researching the next problems that I ran >> into but I thought I'd post an update. First, I ran into >> GCC_NO_EXECUTABLES while the build was in configure-stage2-zlib and in >> anticipating what Lance might say to that, I checked and there doesn't >> seem to be a --without-zlib although I did test that just in case and >> it >> did nothing. The best explanation for what GCC_NO_EXECUTABLES is that >> I >> found so far is in a post to the list about a similar problem: >> >> https://gcc.gnu.org/legacy-ml/gcc/2008-03/msg00515.html >> >> I went ahead and built it anyway with --disable-bootstrap. glibc >> compiled but not too surprisingly running ldd or /usr/lib/libc.so.6 >> with >> LD_LIBRARY_PATH to $DISTRO/usr/lib just segfaults, so it seems like it >> wasn't really a sane build of gcc after all. >> >> Ignoring that problem, configuring libstdc++-v3 after having glibc >> fails >> which is kind of obvious since the host glibc differs in version from >> the target version. You know, the typical "version `GLIBC_2.34' not >> found" errors. This seems like a proper motivating reason for using >> the >> fake cross-compiling trick but I'm determined to figure out if there's >> a >> way around that. > As a LFS editor (and I also have several commits in GCC) I'd say there > is no rational way for this, expect cross-compilation. Maybe you can > use a dozen of switches to accomplish the object, but at last it will be > almost equivelent to run a cross-compilation. > -- > Xi Ruoyao > School of Aerospace Science and Technology, Xidian University >