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

["Arno Schuring" <aelschuring at hotmail dot com>]

see below

----- Original Message ----- 
From: "wim torfs" <wim.torfs3@pandora.be>
To: <crossgcc@sources.redhat.com>
Sent: Saturday, August 28, 2004 1:13 PM
Subject: Re: cross-compiled native compiler: ld can't find crt1.o

> ||Martin Schaffner wrote:
> ||I'm trying to compile LFS starting from Mac OS X for my lfs-from-osx
> ||hint.
yay! I did the same from i386->sparc

(...)

> ||
> ||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

A quick (dirty) solution is to edit the gcc specs file. Look for the *link:
target:

*link:
%{!static:--eh-frame-hdr} -m elf32_sparc (...)

You can add -Y P,[override-path-to-library] here.
It's probably not wise to do this for your definitive toolchain (it
overrides all paths you may have used when configuring binutils), but for
example the LFS /tools toolchain works fine. Actually, I did the same thing
when "re-adjusting the toolchain": I added -Y P,/lib:/usr/lib instead of
re-building binutils.

> 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.

If this is a temporary toolchain, consider the above alternative instead of
recompiling everything.

> 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.

You are right

> 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???

You probably forgot to supply the --build directive. Only when both --host
and --build are supplied (and are different), glibc configures itself for
cross-compilation. (And so, does not run those tests)

HTH,
Arno

>
> 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