[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