From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9192 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Bits deduplication: current situation Date: Mon, 25 Jan 2016 12:17:22 -0500 Message-ID: <20160125171721.GB238@brightrain.aerifal.cx> References: <20160125035925.GA2288@brightrain.aerifal.cx> <20160125090803.2db4a262@ncopa-desktop.alpinelinux.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1453742258 3740 80.91.229.3 (25 Jan 2016 17:17:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Jan 2016 17:17:38 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9205-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jan 25 18:17:37 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aNkll-0003kK-6J for gllmg-musl@m.gmane.org; Mon, 25 Jan 2016 18:17:37 +0100 Original-Received: (qmail 25823 invoked by uid 550); 25 Jan 2016 17:17:35 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 25798 invoked from network); 25 Jan 2016 17:17:34 -0000 Content-Disposition: inline In-Reply-To: <20160125090803.2db4a262@ncopa-desktop.alpinelinux.org> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9192 Archived-At: On Mon, Jan 25, 2016 at 09:08:03AM +0100, Natanael Copa wrote: > On Sun, 24 Jan 2016 22:59:25 -0500 > Rich Felker wrote: > > > I'm about to try starting the bits deduplication, but before getting > > started, I took a quick survey of the current bits headers we have: > > .... > > > Ideas/requests/preferences/etc.? > > It would be nice to be able to build 32-bit boot loaders on 64 bit > hosts with gcc -m32. Currently that does not work due to it picks up 64 > bit inttypes. We have a patch for xen's hvmloader: > > http://git.alpinelinux.org/cgit/aports/tree/main/xen/musl-hvmloader-fix-stdint.patch > http://git.alpinelinux.org/cgit/aports/tree/main/xen/stdint_local.h > > Introduced with this commit: > http://git.alpinelinux.org/cgit/aports/commit/main/xen/musl-hvmloader-fix-stdint.patch?id=bcf7b52774f1b0a3e405a207c3c4a5342b951f40 > > > This is for stdint.h but I think its related and I assume it affects > limits.h too. I don't really see a good way to fix this. musl is not designed for treating "related" 32- and 64-bit archs as if they were a common arch. It would probably not be hard to make this one usage case work in practice, but it would be fragile and incomplete. Is there a reason you can't just pass -nostdinc and then -I the gcc include dir to use gcc's freestanding headers for a non-native target like this? IMO the cleanest (albeit somewhat costlier) solution would be just installing a proper i386 cross compiler. Alternatively maybe gcc's -m32 could be fixed to use completely different include paths rather than trying to use the same headers for different archs. This actually affects third-party installed headers that are generated for the target arch too, which may be wrongly picked up if -m32 is used. Rich