[uClibc] Re: More on config.guess.
Rob Landley
rob at landley.net
Wed Jan 7 03:17:58 UTC 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
i.
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-2.14.90.0.6 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
Rob
More information about the uClibc
mailing list