Re: crosstool and uClibc

["Yann E. MORIN" <yann dot morin dot 1998 at anciens dot enib dot fr>]

Hello all!

Well, first, I have to thank every one stepping in for helping! That's
greatly appreciated.

So far, I have been able to build a seemingly functional uClibc-based
toolchain, except that it will only accept to produce static binaries. See
below for dynamic...

Also, I've tidied up a bit crosstool so that 'multiple' C libraries will be
easier to include (or to remove?). I'm willing to post any work I've done,
but that would mean Dan (or any one else?) will have work to incorporate that
in the next-to-come 0.37. Instead, I'm willing to re-do what I've done once
0.37 is out. Tell me what you'd prefer.

Plus, is it acceptable that all I've done been submitted in one patch, or in
splitted patches, one for each separate and self-contained feature? (my tree
has support for program prefix, silent extractions and run, support of
snapshot tarballs, that is it is systematically downloaded, plus preliminary
uClibc support.) Tell me.

Once upon a time (on Thursday 07 July 2005 15:52), Kai Ruottu wrote :
 >   Or if you now have binutils, some kind of GCC and some kind of C
 > library for your target, why not simply try the obvious thing, to
 > try to compile and link that "Hello World"?  And then see what on
 > earth is wrong with your new (but not yet fully ready) GCC ?
[-- SNIP lightbulbs :-) --]
 >   Just try your "$target-gcc -o hello_$target hello.c" and then report
 > what it says and I think we see many suggestions for fixing your
 > existing GCC or how to rearrange the target libraries and such...

Well, here we are. So far I managed to build a uClibc-based toolchain, with
the following:
binutils-2.15.91.0.2
gcc-3.4.3
uClibc-20050710
linux-2.6.12.2
No sanitized headers were used, as they prevent uClibc from building.
That's Bad in my opinion. So I reverted to a 2.4.29-uc1 kernel (as it has
support for ARM in which I'm greatly interested!)

THe patches I used against gcc were taken from buildroot, in an attempt to
have C++ working. Alas so far it didn't even compile.

The so-built toolchain refuses to build dynamicaly linked binaries with the
folowing error (sorry for long lines):

[ymorin@lesneven ~/dev/tmp]> cat ess.c
#include <stdio.h>
int main( int argc, char** argv ) {
    return printf( "Hello world!\n" );
}

[ymorin@lesneven ~/dev/tmp]> e800-uclibc-gcc ess.c -o ess --verbose
Reading specs from /users/e800-uclibc/lib/gcc/armv5l-xscale-linux-gnu/3.4.3/specs
Configured with: /home/ymorin/dev/armv5l-xscale-linux-gnu/gcc-3.4.3/configure --target=armv5l-xscale-linux-gnu --host=i686-host_pc-linux-gnu --prefix=/users/e800-uclibc --program-prefix=e800-uclibc- --with-headers=/users/e800-uclibc/armv5l-xscale-linux-gnu/include --with-local-prefix=/users/e800-uclibc/armv5l-xscale-linux-gnu --with-float=soft --with-cpu=xscale --enable-cxx-flags=-mcpu=xscale --enable-serial-configure --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-languages=c --enable-shared --enable-c99 --enable-long-long --disable-__cxa_atexit --enable-target-optspace
Thread model: posix
gcc version 3.4.3
 /users/e800-uclibc/libexec/gcc/armv5l-xscale-linux-gnu/3.4.3/cc1 -quiet -v -D__ARM_ARCH_5TE__ -D__XSCALE__ ess.c -quiet -dumpbase ess.c -mcpu=xscale -msoft-float -auxbase ess -version -o /tmp/ccItNf2s.s
#include "..." search starts here:
#include <...> search starts here:
 /users/e800-uclibc/lib/gcc/armv5l-xscale-linux-gnu/3.4.3/include
 /users/e800-uclibc/lib/gcc/armv5l-xscale-linux-gnu/3.4.3/../../../../armv5l-xscale-linux-gnu/sys-include
 /users/e800-uclibc/lib/gcc/armv5l-xscale-linux-gnu/3.4.3/../../../../armv5l-xscale-linux-gnu/include
End of search list.
GNU C version 3.4.3 (armv5l-xscale-linux-gnu)
        compiled by GNU C version 3.2.1.
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64374
 /users/e800-uclibc/lib/gcc/armv5l-xscale-linux-gnu/3.4.3/../../../../armv5l-xscale-linux-gnu/bin/as -mcpu=xscale -mfpu=softfpa -mfpu=softfpa -o /tmp/ccgdio1P.o /tmp/ccItNf2s.s
 /users/e800-uclibc/libexec/gcc/armv5l-xscale-linux-gnu/3.4.3/collect2 --eh-frame-hdr -dynamic-linker /lib/ld-linux.so.2 -X -m armelf_linux -p -o ess /users/e800-uclibc/lib/gcc/armv5l-xscale-linux-gnu/3.4.3/../../../../armv5l-xscale-linux-gnu/lib/crt1.o /users/e800-uclibc/lib/gcc/armv5l-xscale-linux-gnu/3.4.3/../../../../armv5l-xscale-linux-gnu/lib/crti.o /users/e800-uclibc/lib/gcc/armv5l-xscale-linux-gnu/3.4.3/crtbegin.o -L/users/e800-uclibc/lib/gcc/armv5l-xscale-linux-gnu/3.4.3 -L/users/e800-uclibc/lib/gcc/armv5l-xscale-linux-gnu/3.4.3/../../../../armv5l-xscale-linux-gnu/lib /tmp/ccgdio1P.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /users/e800-uclibc/lib/gcc/armv5l-xscale-linux-gnu/3.4.3/crtend.o /users/e800-uclibc/lib/gcc/armv5l-xscale-linux-gnu/3.4.3/../../../../armv5l-xscale-linux-gnu/lib/crtn.o
/users/e800-uclibc/lib/gcc/armv5l-xscale-linux-gnu/3.4.3/../../../../armv5l-xscale-linux-gnu/lib/libgcc_s.so: undefined reference to `dl_iterate_phdr'
collect2: ld returned 1 exit status

Any one has any idea?

I'll be rebuilding a toolchain with the crosstool patches against gcc
and see if that works.

TIA,
Yann.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |   ^                |
| --==< °_° >==-- °---.----------------:  X  AGAINST      |  /e\  There is no  |
| web: ymorin.free.fr | SETI@home 3808 | / \ HTML MAIL    |  """  conspiracy.  |
°---------------------°----------------°------------------°--------------------°
 \__ np:  [Stopped] __________________________________________________________/


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