From: Gregor Richards <gr@purdue.edu>
To: musl@lists.openwall.com
Subject: Re: [PATCH 9/10] GLIBC ABI patches
Date: Tue, 24 Jul 2012 14:29:11 -0400 [thread overview]
Message-ID: <500EE977.70205@purdue.edu> (raw)
In-Reply-To: <77170945-3310-4E43-A57E-D5B00974DCA0@palsenberg.com>
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
next prev parent reply other threads:[~2012-07-24 18:29 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-23 1:13 [PATCH 1/10] ioperm & iopl Isaac Dunham
2012-07-23 1:17 ` [PATCH 2/10] splice Isaac Dunham
2012-07-23 1:21 ` [PATCH 3/10] xattr syscalls Isaac Dunham
2012-07-24 18:06 ` orc
2012-07-23 1:24 ` [PATCH 4/10] pipe2 Isaac Dunham
2012-07-23 1:28 ` [PATCH 5/10] __sigsetjmp alias Isaac Dunham
2012-07-23 1:32 ` [PATCH 6/10] Provide private versions of locale/ functions Isaac Dunham
2012-07-23 1:33 ` [PATCH 7/10] __fcntl Isaac Dunham
2012-07-23 1:36 ` [PATCH 8/10] finite Isaac Dunham
2012-07-23 7:58 ` Szabolcs Nagy
2012-07-23 1:38 ` [PATCH 9/10] GLIBC ABI patches Isaac Dunham
2012-07-23 15:11 ` Arvid E. Picciani
2012-07-24 18:15 ` Igmar Palsenberg
2012-07-24 18:19 ` Gregor Richards
2012-07-24 18:23 ` Igmar Palsenberg
2012-07-24 18:29 ` Gregor Richards [this message]
2012-07-24 18:33 ` Igmar Palsenberg
2012-07-24 23:18 ` Rich Felker
2012-07-25 7:27 ` Arvid E. Picciani
2012-07-25 14:12 ` Luca Barbato
2012-07-25 15:19 ` Rich Felker
2012-07-25 15:52 ` Luca Barbato
2012-07-25 17:35 ` Rich Felker
2012-07-25 23:06 ` idunham
2012-07-23 1:40 ` [PATCH 10/10] More glibc ABI compatability Isaac Dunham
2012-08-07 2:22 ` [PATCH 1/10] ioperm & iopl Isaac Dunham
2012-08-07 3:29 ` Isaac Dunham
2012-07-25 3:00 [PATCH 9/10] GLIBC ABI patches idunham
2012-07-25 15:06 ` Rich Felker
2012-07-25 22:19 ` Luca Barbato
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=500EE977.70205@purdue.edu \
--to=gr@purdue.edu \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).