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

[Dan Kegel <dank at kegel dot com>]

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


--
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change

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