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=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11892 invoked from network); 10 May 2020 21:53:12 -0000 Received-SPF: pass (mother.openwall.net: domain of lists.openwall.com designates 195.42.179.200 as permitted sender) receiver=inbox.vuxu.org; client-ip=195.42.179.200 envelope-from= Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 10 May 2020 21:53:12 -0000 Received: (qmail 19981 invoked by uid 550); 10 May 2020 21:53:10 -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 19961 invoked from network); 10 May 2020 21:53:09 -0000 Date: Sun, 10 May 2020 17:52:57 -0400 From: Rich Felker To: Michael Forney Cc: musl@lists.openwall.com Message-ID: <20200510215257.GW21576@brightrain.aerifal.cx> References: <20181107064957.1137-1-mforney@mforney.org> <20200323043456.13327-1-mforney@mforney.org> <20200510163555.GU21576@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Re: [musl-cross-make] [PATCH v2] litecross: Fix system header dir when building native toolchains On Sun, May 10, 2020 at 01:35:23PM -0700, Michael Forney wrote: > Thanks for your response, Rich. > > On 2020-05-10, Rich Felker wrote: > > Sorry I haven't had the time/attention to devote to this. I think > > there's still a major mismatch in expectations -- the system you > > install this native compiler onto is not going to have its include > > files in /include but the standard /usr/include, among a lot of other > > things. > > 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.... > 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). 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. Rich