[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <500EE977.70205@purdue.edu>
Date: Tue, 24 Jul 2012 14:29:11 -0400
From: Gregor Richards <gr@...due.edu>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 9/10] GLIBC ABI patches
On 07/24/12 14:23, Igmar Palsenberg wrote:
>
>>>>> Just nonsense aliases GNU uses...
>>>>> Needed for ABI compatability.
>>>> could we mark them as such? at least with a comment.
>>>> I really like that musl is so readable. This patch adds some obfuscation that can simply be countered by marking it as "ok this is only here for reason X."
>>> I would like to see those options behind a compile time option : It bloats musl with in many cases unneeded code. I test my compiles with musl, and I like it lean and mean.
>> These are just aliases, not code. There's no bloat there.
>>
>> One of the advantages of musl is its LACK of configurability: If you have “musl”, you know what precisely you're getting.
>>
>> With valediction,
>> - Gregor Richards
>>
> While I agree with the above, I still have a few objections :
>
> - We don't want glibc compatibility. We want a good libc.
> - That we even need those aliases is usually a case of bad automake / autoconf / bad feature detection.
>
> Why bloat code with stuff to provide glibc compatibility ?
>
>
> Igmar
“That we even need those aliases is usually a case of bad automake /
autoconf / bad feature detection”
These are for ABI compatibility, not API compatibility. Nobody using
glibc uses these symbols intentionally, they are renamed and aliased by
the library. Last I checked, musl is shockingly close to ABI
compatibility with glibc, and like it or not, that's a valuable feature.
If you don't like the “bloat” of it, you'll have to dig out a lot of the
existing aliases too.
With valediction,
- Gregor Richards
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.
