crt0 in toolchain

Peter S. Mazinger ps.m at gmx.net
Fri Dec 2 13:36:19 UTC 2005


On Thu, 1 Dec 2005, [Windows-1251] Àëåêñàíäð Íèêóëèí wrote:

> Hi, All.
> 
> 
> My primary msg was:
> >> Hi, All.
> >>
> >>
> >> I built my ARM toolchain with binutils-2.16.1, gcc-4.0.2 and uClibc-0.9.28.
> >> Linux kernel 2.6.14 works on target mashine. But linker
> >> searches for crt0.o, when I try to build busybox-1.01. 
> >> There is no such file for ARM arch. 
> >> Only --prefix and --target compiler options were used for cross-gcc building.
> >> Please explain, where my mistake(s) is(are) or refer me to any usefull URL.
> 
> Thank you Allan, Mike and all others!
> 
> But "no ready toolchain" is main condition for my task, I have to
> build myself.
> 
> It's OK, if "newlib" was used for cross-gcc building (have found somewhere
> in the Internet):

if you want to use uClibc, don't use newlib ... (even if have seen 
--with-newlib somewhere as a gcc configure option, that means only - as of 
gcc - that we do not have glibc, nothing newlib specific)

>   $ pwd
>   $ ...../gcc-4.0.2
>   $ ln -s ...../newlib-1.13/newlib .
>   $ cd ..
>   $ srcdir/configure --prefix=.....
>                      --target=xscale-elf
>                      (no anything more!)
> Then cross-gcc works qiute correct, since newlib builds crt0.o,

you need crt1.o

> BUT newlib also builds own libc.a-and-others and include dir.
> I don't know about libc.a contents but include dir does not approach
> to busybox requirments. I tryed replace libraries with uClibc analogs

you need the uClibc versions

> (bad way!!!), but newlib object files are incompatible with uClibc
> libs. And, in general, it is a nasty situation, then there are TWO C
> libraries in toolchain. So I removed newlib symlink from gcc source
> tree and began to try further. The search in the catalogue
> gcc-4.0.2/gcc/config/arm gave me the following results:
> 
> file unknown-elf.h contains
> #undef STARTFILE_SPEC
> #define STARTFILE_SPEC <something with crt0>

if you haven't used buildroot, then you at least need the binutils/gcc 
patches used there, else you miss proper uClibc (specifically arm) support 
in gcc
 
> Using #error directive inserting I have found out, that generates
> a file tm.h during compilation which #include unknown-elf.h.
> I changed --target with xscale-linux-elf, so "configure"
> 
> checking target system type...   xscale-linux-elf

wrong, the tuple is arch*-*-linux-uclibc* so your's could be
arm-xscale-linux-uclibc (armv5l is probably ok for you too iirc, 
specifying arm version 5 little endian)

> 
> no xscale-unknown-elf like earlier.
> I really believed that all will be OK, but tm.h comprised
> #include unknown-elf.h   again!

use gcc patches from buildroot as stated above

> 
> Of course I can remove unknown-elf.h or replace crt0 in
> #define STARTFILE_SPEC with crt1, for example, or make another
> nonsense. By the way, guys, what crtXXX are?! What a difference
> between them? Give me please any useful doc or URL!
> 
> I guess that problem is in gcc configure options, but I don't know
> where.
> 
> Sorry, guys for:
> 
> 1. Any errors in pathes, files contents and others (I make this msg
> not on my computer).
> 2. Maybe silly questions (first time in toolchain creating and usage)

then it is better to start w/ buildroot, that can build the toolchain for 
you...

> 3. My bad English.

nop

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2




More information about the uClibc mailing list