Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 25 Jan 2016 12:17:22 -0500
From: Rich Felker <>
Subject: Re: Bits deduplication: current situation

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:
> Introduced with this commit:
> 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.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.