[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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.
