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

Manuel Novoa III mjn3 at codepoet.org
Tue Jan 6 23:45:47 UTC 2004


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...

> > > 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.
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.

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.

Manuel




More information about the uClibc mailing list