Re: cross-compiled native compiler: ld can't find crt1.o

[wim torfs <wim dot torfs3 at pandora dot be>]

||Martin Schaffner wrote:
||I'm trying to compile LFS starting from Mac OS X for my lfs-from-osx
||hint.
||
||I used crosstool (http://kegel.com/crosstool) to create a
||cross-compiler on Mac OS X for powerpc-750-linux-gnu, whose specs file
||I modify to use /tools/lib/ld.so.1 instead of /lib/ld.so.1.
||With this cross-compiler, I compiled glibc-2.3.2 (as patched for
||crosstool), gcc-3.3.3 and binutils-2.14 (patched and compiled as 
||in the sections "Pass 2" of LFS-5.1.1 plus the host and build
|| configure |flags).
||
||After starting Linux with init=/tools/bin/bash, the compiler 
||in /tools/ can compile a hello world program fine, but it can't 
||link it.
||
||The first problem is that in the arguments to ld, gcc passes crt0.o,
||crt1.o, and crtn.o directly, without any path prefixed, so ld can't
||find them.


|Heh.  I've run into that.  It means your toolchain is not installed
|quite right.
|The -print-file-name option to gcc can be used to check whether gcc can
|find
|a particular file.  e.g.
|$ gcc -print-file-name=crt1.o
|/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../crt1.o
|If it can't find it, it'll print it out with just a bare filename,
|just as you're seeing.


|The way to solve this is to look at the gcc source code to understand
|what the -print-file-name= option does, and work backwards from there.
|It's not fun, but hey, at least you get to see how things work.
|- Dan


I'm sorry, I'm new to this matter, but I have the same problem.

I looked as Dan mentioned to the file gcc passed to ld.
It searches somewhere in my /usr/lib/gcc/... directory.
the crt1.o file isn't there, it is positioned in the /usr/lib directory.

agreed until there, the linker can't find the crt1.o file.

there is one thing though that I don't quite get.

I've build the kernel headers, binutiles, glibc-headers and gcc(first
step).
That arm-linux-gcc is looking in /usr/lib/gcc/...
when I build glibc for running on an ARM target, I get stuck at the
configure step, because there is a test for calculating the size of a
long, where it uses the arm-linux-gcc, hence the configure step fails.

If I'm right, the crt1.o is generated by the glibc install.

Now my question: should the arm-linux-gcc search for the
/usr/lib/gcc.../crt1.so or the one generated by the arm compiled glibc?
I thought the second one, but how to compile glibc when there is no
crt1.o yet???



Wim






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