From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 6318 invoked from network); 13 May 2020 08:18:21 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 13 May 2020 08:18:21 -0000 Received: (qmail 21981 invoked by uid 550); 13 May 2020 08:18:19 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 21963 invoked from network); 13 May 2020 08:18:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mforney-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EH8qsV7IC+0l2t1fkq5IsKL16QDt9zoV+MvpvihHTs8=; b=vWTABGSwQJO1bPlv1bQz6z8sYyeLqu/so5rF259cXdIb7q9KZrBk36oywrvXM3cPr6 uGZKoP9fBztM+MOGQr77h68IKy5fG+1cD6z6aQ+d7dUhKpI4wKZWWpCtm/zIBmEZSVKr l5rQtzo7FBRB4Q9ir2dwGEc1YW9Op7w8dHSXHfrC844WyPSH9XzKcIWEbZ1A8GKwoKzf v+g70fc6HaLZCxBP3NRdxNLQrR9b4SY2+kYgb/Hqy1klRYiUSo6wPAu4EKHQFRVRgzdl hunA+4Bjks2S9IaKeh4vCEPniUaWdCDqlD20fXLtgP3jLkAqgEGvBMc3plxV5J/d9+YJ YyfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EH8qsV7IC+0l2t1fkq5IsKL16QDt9zoV+MvpvihHTs8=; b=NvVkde569xq15HahCd4iZKvTA5yVq7QWxv/wQUc+500h3189sqqX0sPU7o15pUx1/W 6HtcVMsXkDFA9xY9np8cayXhTbK1h5HnyFDrPzVWKby326fD28KhUA+P+2kqjCyYV1wN jVNfb86m9b9UwVD1yOQPv1S3BzCEwV4vJTEicHz5RawBGiRvSXkUNoqg2RTtDXNN2q20 zPveWB7x6KuevMIN0VRG+hD9Pa7ZLMY3DirqrlzSQwc/hNM19RBsaXy5FtwIXEZxZ5wt G0Y56vILdOymrIUAN7a5d0xM5rYX5q296oViHl5UeNF/Yi0mIVwni+c8LvQvTUOTWNly OdPA== X-Gm-Message-State: AGi0Pua+3TsxYtcAV00DGNU8TaUHmFt7Xk1CvTxO4BnEhwQYyLnr/3yY 6mBqVBZHUvMxpC/hIUQGSOLbkfh/aS4XBVlzQ5QmVg== X-Google-Smtp-Source: APiQypIqdSB8MofGSwPpuehbAgZJ4S6c+sQgpkwAxGODvHIfXfWKFK0HSucWKI17ek/HDA339SNzsD7JOH3sErEOo28= X-Received: by 2002:a6b:720d:: with SMTP id n13mr10585281ioc.20.1589357886847; Wed, 13 May 2020 01:18:06 -0700 (PDT) MIME-Version: 1.0 X-Originating-IP: [73.70.188.119] In-Reply-To: <20200510215257.GW21576@brightrain.aerifal.cx> References: <20181107064957.1137-1-mforney@mforney.org> <20200323043456.13327-1-mforney@mforney.org> <20200510163555.GU21576@brightrain.aerifal.cx> <20200510215257.GW21576@brightrain.aerifal.cx> From: Michael Forney Date: Wed, 13 May 2020 01:18:05 -0700 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] Re: [musl-cross-make] [PATCH v2] litecross: Fix system header dir when building native toolchains On 2020-05-10, Rich Felker wrote: > On Sun, May 10, 2020 at 01:35:23PM -0700, Michael Forney wrote: >> My understanding was that musl-cross-make toolchains (native or cross) >> were meant to be self-contained units, so the include directory >> relative to the sysroot is always /include. > > This is true for cross compilers, which were the original only > in-scope task of musl-cross-make. Adding NATIVE=y mode was a quick > hack that was later fleshed out somewhat, but there was never any > real design behind how it should work, and it shows. I'm not really > sure whether it should be a proper native compiler for the target, or > effectively a sysrooted self-targeting cross compiler that runs on the > target. In some sense these are two different things and the user > should be aware of which one they're requesting/getting.... Again, forgetting NATIVE=1 compilers entirely, this still fixes a bug for cross-compilers that is currently hidden by the fact that the sysroot (/$TARGET) happens to match the gcc tool directory. >> Merging a native toolchain into / can't work, even using the default >> /usr/include search directory, because you'd still have musl headers >> installed into /include, so the compiler would be unable to find the >> musl headers (this is the same reason why you currently need the usr >> -> . symlink). To support something like this, I think you'd need to >> make the prefix configurable. > > I think the symlink is just missing (not done via the same rule as for > cross compilers because the sysroot base is different for a non-cross > compiler). I don't quite understand what you mean here, or why you think a symlink should be necessary in the first place. The sysroot base doesn't matter here; for both native and cross toolchains, musl-cross-make installs musl headers to $SYSROOT/include ($OUTPUT/include for native, and $OUTPUT/$TARGET/include for cross). Currently, gcc is searching for headers in $SYSROOT/usr/include, as it does by default, but we can configure gcc to instead search $SYSROOT/include (where the headers actually are) by using --with-native-system-header-dir=/include. What I meant above is that if you were to try to merge a musl-cross-make toolchain into /, you'd have two separate directories, /include containing the toolchain headers, and /usr/include containing the system library headers. gcc would only search for headers in /usr/include, and you couldn't use a symlink since both are separate directories with separate contents. To support this, you'd need to set --prefix=/usr and install musl headers to $SYSROOT/usr/include, but I think this is probably out of scope of musl-cross-make (at least, out of scope of this patch). Also note that the proposed patch does not conflict with a change like this, you'd just set --with-native-system-header-dir=$(PREFIX)/include instead. > At least relative to what I remember of my original intent. > But I'm doubtful that this was well thought out at all since the only > real intent at the time I added it was "can I make a compiler run on a > nommu j2?" where I didn't want to bootstrap a whole distro or have > anything serious actually compiled on the target where it would have > been prohibitively slow. I get that you're unhappy with the current state of musl-cross-make and NATIVE=1, and sure, there are probably some improvements to be made, but I think you're making this out to be trickier than it actually is. Once you have time to take a closer look at this, I think you'll find that it really is a simple issue of gcc searching the wrong directory by default.