Re: [PATCH 9/10] GLIBC ABI patches

[Igmar Palsenberg <igmar@palsenberg.com>]

>>>>>> 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.

I've seen lots of code who use internal glibc functions / data structures. We want to prevent them from being used, that's why I personally have a problem with adding code like this. Unless it actually serves a real use.



	Igmar