[uClibc] Re: Query about uclinux/uclibc ABI and system tuple.

[Rob Landley]

On Tuesday 06 January 2004 17:45, Manuel Novoa III wrote:
> On Tue, Jan 06, 2004 at 07:57:33AM -0600, Rob Landley wrote:
> > On Tuesday 06 January 2004 06:17, Erik Andersen wrote:
> > > > C) The uclinux abi currently changes based on version (hence the * at
> > > > the end for version info),  but also changes based on configuration. 
> > > > Is there some standard way to detect the configuration elements in a
> > > > uclibc system that change the abi, and somehow encode them in the
> > > > version info on the end of the string?  (A series of letters
> > > > indicating non-default options, perhaps? uclibc0.96tp, t for no
> > > > threads, p for no position independent code?)
> > >
> > > mjn3 and I have discussed this very thing, but have never gotten
> > > around to implementing it.
> >
> > Is there a cannonical list of major options that affect ABI?
>
> thread, wide char support, the various levels of locale support, other
> stdio fine-tuning config options, sys_errlist and sys_siglist...

The "..." implies to me it's not quite a complete list. :)

Hmmm... thread=t, wide char=w.  Cool.  So the most recent library with 
everything but those would be "i386-pc-linux-uclibc0.9.26tw"

If you're compiling the thing for uclibc, you should just assume that 
sys_errlist and sys_siglist are not there.  This is a search and replace, if 
they're supporitng uclibc at ALL, it's a trivial change to make.  (Even on a 
desktop system, it just doesn't buy you anything.)

As for the rest: stdio might=s, but not if there's more than one option...  
Same with locale.  I guess I'll look at the uclibc menu:

Everything in the "Target Architecture Features and Options" menu really 
belongs in the first three tuples.  (Endianness is part of #1 or #2, has an 
mmu ditto, presence of an FPU is part of #1...)

Why is "Enable full C99 math library support" under the architecture menu?  
Shouldn't that be under General LIbrary Settings?

As for General Library Settings: there's a lot of stuff you can switch off, 
but how much of it do we care about?  For one thing, modern systems are 
pretty much ALWAYS going to want Shadow Password Support, Unix 98 PTYs, 
/dev/pts, large file support...  Is there anything in here we want to note 
the switching off of?  (uclibc has 8 gazillion possible binary APIs, but I'm 
only looking for the major ones people might want to base a distro around.)

The default should be that they do NOT have sys_errlist and sys_siglist We 
should probably just assume they NEVER have sys_errlist in a uclibc 
application (because there is no POINT).  This is a search and replace, if 
they're supporitng uclibc at ALL, it's a trivial change to make...

Networking support has IPV6 and RPC.   (I personally never use either.)  I 
suppose we should distinguish between "things you can't use if you don't 
enable them" and "things that affect other things even when you're not trying 
to use them".  If this is the first category, I guess it doesn't REALLY need 
an annotation...  But does toggling ipv6 mess with ipv4 support?

Okay, I'm down to the locale stuff.  I guess the only levels we currently care 
about are no locale vs locale support.  (Once extended locale is stable, I 
guess that "locale" will include extended locale support.  In for a penny...)
Beyond that, I dunno what you mean by stdio fine-tuning options.  (There are a 
few "support buggy programs" options, but that gets us back to sys_errlist 
and sys_siglist, pandering to broken code is not a part of the API I propose 
to annotate.  Assume that if they're distributing uclibc binaries, they've 
done some basic cleanup work on their code for this sort of thing.)

There's a "big and tall" menu?  Right...  More "only affects stuff that uses 
it" API, I suppose...

OK, so that gives us:

t=no thread support.
w=no wide char support
l=no locale support (includes w, no need to put both).

And to be honest, wide char support and locale support can be bundled together 
and called "i" for internationalization.  For distributing APIs, either you 
have both or you have neither, the potential audience that wants one but not 
the other is probably not worth distributing precompiled binaries for.  
(Either your distro handles internationalization, or it doesn't.)

That gives us 4 possible APIs: uclibc#, uclibc#t, uclibc#i, uclibc#ti.  (With 
# being the version number.  For the moment, the version number's the full 
0.9.26, but once we go to 1.0 it just becomes 1.  "uclibc1ti"...

Sound like a plan?  What did I miss?

> > > > Is there a way to autodetect this stuff for config.guess?  (Some
> > > > option to ldd, perhaps?)
> > >
> > > include/features.h from uClibc includes bits/uClibc_config.h,
> > > which provides a #define for each enabled uClibc compile-time
> > > option.
> >
> > Is this installed on the final system as part of the headers? 
> > (Rummages...) Cool, it is.
> >
> > So basically, config.guess can look for /usr/include/bits/uClibc_config.h
> > to see if uClibc is installed, and then grab additional config info it
> > needs based on the contents of the file.  Cool. :)
> >
> > So I just need to know what the relevant config options are, and it's a
> > simple question of shell scripting.
> >
> > Query: is adding letters for things that are NOT installed a good
> > strategy (on the theory that a uClibc with everything it can do switched
> > on is the "normal" case)?
>
> I would recommend anyone wanting to use uClibc in a desktop-like
> distribution standardize on a config enabling all functionality.

Yup.  That's why switching stuff _off_ would be what adds letters.  The 
default (with everything on) is just "i386-pc-linux-uclibc0.9.26".

> ABI changes in the works...  the FILE layout will change by this
> weekend when I check in the new stdio core.  It will change on more
> time this month because I need to add a field to track what codeset
> conversion is associated with the FILE.  Also, I plan to stabilize
> the locale API this month.

That's why version number is part of the tuple.

Once we go to a stable API, we can just use the major version number.  
"i386-pc-linux-uclibc1ti".  (Another good reason to use "i" instead of l:  
"uclibc1l" looks too much like "uclibc11" in some fonts, and dropping 
internationalization saves a LOT of space and complexity, and lets you drop a 
couple user-mode packages like gettext too.  Of course it also cuts your 
distro off from 50% of the world's economy...)

Mostly, I'm preparing for the 1.0 switchover.  Distributing uclibc binaries 
before then doesn't make much sense, but when 1.0 DOES ship I'd like to have 
the infrastructure in place.  I think I have the info to hack together a 
config.guess extension now, although I'd like to get agreement (or at least 
"explicit lack of objections") from you, Eric, and bug1 before proceeding.

> In case you missed another post of mine, I almost have gcc 3.3.2
> and binutils-2.14.90.0.6 building "normally".  No sed hacking involved,
> and the only patching left to remove is related to stdlibc++...
> particularly wrt locale support.

Cool.  Let me know how this works out.

I almost have a Linux From Scratch 5.0 building, and when I get the full 
system working using the standard LFS tools and utilities (all the GNU 
stuff), I'm going to start replacing things with busybox and uclibc.  But 
first, I'm going to be incommunicado for a couple days.  Road trip!

> Manuel

Rob