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.