[uClibc] Re: [patch] Inform config.guess about the existence of uclibc.

Rob Landley rob at landley.net
Sun Jan 11 08:39:48 UTC 2004


On Saturday 10 January 2004 23:37, Manuel Novoa III wrote:

> I like the idea of different names.  But I think it would be better
> for us to do all the processing in uClibc_config.h itself and provide
> a single identifier for config.guess to check.  That way, we isolate
> config.guess from any future uClibc changes that we might wish to flag.
>
> Manuel

Works for me.  Let me know what you come up with. :)

Personally, I'd like to minimize the number of different names.  There are 
just too many different possible binary APIs (including every possible bit of 
functionality you can switch off that doesn't affect anything unless you try 
to use that particular function).  Figuring out what should be in the flag 
list is going to require a judgement call from somebody like Erik, I suspect.

What will probably happen in practice is if a uclibc-based distro becomes 
popular, its ABI will become standard.  Binaries will be "for uclibc debian", 
or "for uclibc fedora".  We can largely punt on that.  config.guess really 
shouldn't care TOO deeply since specific features can be tested for by 
autoconf anyway.

What we may want to do instead is have a few predetermined config files that 
we ship with the system, and if you use one of these config files you get a 
known stable binary API.  (Without internationalization, without threading, 
with everything...)

How tough is it to test the ABI at runtime with some kind of diagnostic 
program or precompiled test suite?  (If nothing else, this would let people 
tweak the ABI a bit themselves and see what causes binaries to need to be 
recompiled.)  What kind of program would not only have good coverage but 
would give you good failure messages?  ("Networking doesn't work", etc.)  How 
big of a project would that be?

Rob




More information about the uClibc mailing list