[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK4o1Ww1-xF_UAGabPtsqFjRGgZsZdKc65n-fPrZ4duCRXp8+Q@mail.gmail.com>
Date: Mon, 29 Dec 2014 21:29:22 +0000
From: Justin Cormack <justin@...cialbusservice.com>
To: musl@...ts.openwall.com
Subject: Re: the case for __MUSL__
On Mon, Dec 29, 2014 at 5:59 PM, Josiah Worcester <josiahw@...il.com> wrote:
>
> On Dec 29, 2014 11:51 AM, "Richard Gorton"
> <rcgorton@...nitive-electronics.com> wrote:
>>
>>
>> That is a single example of some of the code in a library which is NOT
>> musl.
>> There are other places in the example library which know about __APPLE__
>> or __GLIBC__ or __sun__
>>
>> My thought is to use __MUSL__ in those libraries as appropriate in place
>> of __<architecture>__ as the backing libc is musl.
>>
>> And said use of __MUSL__ is what I am interested in feedback about.
>>
>
> The intent of not providing it is to force applications to use a portable
> interface rather then being libc specific. So, everyone's leaping to try and
> find ways to not need that.
> Sorry for the mismatched expectations.
There are cases where glibc uses a non standard/bizarre/buggy
interface and using #ifdef __GLIBC__ and leaving Musl to use the sane
default case works. Best to avoid those if at all possible though.
Justin
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.
