Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 24 Jul 2012 23:00:54 -0400 (EDT)
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.

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
The point would be to allow removing gnuish extensions without too much
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.