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.