[uClibc] Re: More on config.guess.

Rob Landley rob@landley.net
Wed Jan 7 03:18:00 GMT 2004

On Tuesday 06 January 2004 17:31, Manuel Novoa III wrote:
> Hello,
> On Tue, Jan 06, 2004 at 07:45:36AM -0800, Dan Kegel wrote:
> > >Its hard to know, but a number of autoconf macros rely on the values
> > >generated by config.guess.
> >
> > Oddly, config.guess doesn't contain the string 'uclibc' or 'uclinux'.
> > Wonder what it outputs when running on a uclibc system...
> It returns <ARCH>-<*>-linux-gnu, but that is easy enough to fix.

We've been having a little discussion of this on the uclibc mailing list (not 
cc'ing the people beyond the list).  I think I have the info necessary to 
make a config.guess script now.  It's (currently) looking like the identifier 
will be uclibc plus the version number, optionally plus the letters t and or 

With t meaning "lack of thread support" and i meaning "lack of 
internationalization support".  (Four possible binary APIs.)

Before 1.0, the binary API is still fluid, so the version number has to be the 
whole "0.9.26".  (I.E. "i386-pc-linux-uclibc0.9.26" or 
"i386-pc-linux-uclibc0.9.26ti".)  After 1.0, the binary API will stabilize 
and we'll only need the major number ("i386-pc-linux-uclibc1i").

This isn't set in stone yet, but if this proposal's acceptable (and the uclibc 
guys don't object that I'm paring the ABI selections down too much), I'm 
volunteering to patch config.guess (and I suppose update config.sub if 
necessary) after my road trip.  I think I know how to autodetect all the 
variants mentioned above on a running system, including version numbers.  
(Check for the existence of /usr/include/bits/uClibc_config.h to detect 
uclibc, then examine its contents to determine the details.)

> > Here's some discussion from when Bernardo was picking the system name:
> > http://gcc.gnu.org/ml/gcc-patches/2003-09/msg01136.html
> > which notes that *-uclinux-uclibc is a good tuple which is significantly
> > different from *-linux-uclibc in that it uses flat ELF files
> > rather than normal ones.
> >
> > Does anyone know if any program needs to behave differently for
> > *-linux-uclibc
> > as opposed to *-linux-gnu (besides gcc)?  I imagine it might
> > change a couple defaults in the cross-compile case for some autoconf
> > tests, at least...
> We really need a seperate tuple in order to coexist with glibc.

And the ABI is _wildly_ different.  A glibc binary won't come close to running 
on a uclibc system, and vice versa.

(All this may actually make RMS a happy guy, because it's another way to make 
the "here's a proprietary binary" people hate us.  Of course, technically, 
the terms of the LGPL already cover this, if they linked with glibc.  We may 
actually start enforcing this: "Hey $COMPANY, give us a .o file so we can 
link your program against uclibc..."  "I don't wanna support that!"  "I'm not 
asking for tech support, but the license terms say...")

That's going to be interesting...

> For what it is worth, I just about have binutils- and
> gcc-3.3.2 building "normally" for *-linux-uclibc.  I'm hoping to
> have that finished by the end of he week.  I still need to work
> around some stdlibc++/locale issues.

The config.guess editing looks like something I could finish in a weekend.  
(The hard part's going to be setting up a test system where the two coexist 
without screwing up my laptop...)  However, I'm off on a road trip later this 
evening, and will be incommunicado for a couple days...

> Manuel


Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com

More information about the crossgcc mailing list