[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120724231833.GM544@brightrain.aerifal.cx>
Date: Tue, 24 Jul 2012 19:18:33 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 9/10] GLIBC ABI patches
On Tue, Jul 24, 2012 at 08:33:31PM +0200, Igmar Palsenberg wrote:
> >> 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.
>
> 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.
OK, let me clarify a bit of musl's policy about glibc compatibility.
The intent is that programs or .o files built against glibc headers
and linked against glibc libc.so should work on musl as long as they
are conforming C/POSIX programs or programs which just use nonstandard
but widely available functions provided by musl and which are
otherwise conforming C/POSIX programs. There's no explicit goal of
supporting glibc programs which are poking at glibc internals (like
the stdio hacks in gnulib) or otherwise dependent on the way glibc
implements a particular interface, since one of the major goals of
musl is to be able to drop and replace the internals of any interface
with a new/better implementation without breaking programs linked
against musl libc.so.
To achieve the above level of glibc ABI compatibility, it's necessary
to provide a minimal set of symbols not specified by C or POSIX but
which glibc uses for implementing things specified by C or POSIX. One
good example is the __isoc99_*scanf functions. Since glibc's plain
*scanf functions are nonconformant, building against glibc with
-std=c99 causes the program to use the __isoc99_*scanf functions
instead. This is not a glibc-specific hack in the program but instead
a hack induced by the glibc header files. There's also minimal cost in
supporting it; it's just an extra symbol in the global symbol table,
no extra code. Other examples are the *64 functions for 64-bit off_t
support. An example where there is some actual code/data bloat is the
tables used for implementing ctype.h is*() functions. I added these
with some hesitation, but unfortunately they're necessary to be able
to run any conforming C program that was built against glibc which
happens to use ctype.h, and thankfully they're not too big.
With that said, there's also some benefit to being able to use nasty
binaryware video drivers that were built against glibc, specifically
the nvidia junk. I'm not a fan (personally, I would never buy an
nvidia card until their policies change, and even then I'd be hesitant
to buy the watt-guzzling SUV of video cards...) but many people have
them and want to use them, and being able to get the driver working
with musl is quite a nice hack. So if we can provide the symbols or a
minimal amount of compatibility glue to make these drivers work, I
think it's worthwhile to do so.
Rich
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.
