Date: Tue, 24 Jul 2012 23:00:54 -0400 (EDT) From: idunham@...abit.com To: musl@...ts.openwall.com Subject: Re: [PATCH 9/10] GLIBC ABI patches > >>>>>>> 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 >> >> 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 The real use here, from what orc was saying, is running the proprietary nvidia driver on a musl-based system. Rich: I have three questions: 1. Should it be possible to weak_alias an externally defined function? ie, src/stdlib/strtod.c defines strtod, then src/glibc-abi/stdlib.c goes: #include "libc.h" #include <stdlib.h> weak_alias(strtod, __strtod_internal) 2. Would this result in obfustication of the source? 3. Would a subdirectory of src/ solely for glibc ABI/API compatability be appropriate? The point would be to allow removing gnuish extensions without too much trouble. Even if 1 or 2 mean that weak_alias stuff goes in the same file, this could contain functions like the ones added for gnulib (src/stdio/ext*.c). Isaac Dunham
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.