This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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 ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |