relocating the compiler and associated tools
Arno Schuring
aelschuring@hotmail.com
Tue Nov 9 14:23:00 GMT 2004
> >
> > >
> > > i then copied all of .../gcc-3.4.1-glibc-2.3.3/ to /usr/local/sh3,
> > > and reset my PATH to instead include /usr/local/sh3/bin. ran same
> > > test compiles, got the same output. i realize this doesn't constitute
> > > a rigorous test, but it seems promising. (once i read more, i'll
> > > probably realize that i didn't need to copy *everything* from that
> > > results directory over to /usr/local/sh3 but better safe than sorry).
> >
> > Well, that depends... did you *copy* everything or did you *move* the
>tree?
>
>"cp -a" since it was in a different filesystem. is that a problem?
>
Could be...
The first problem I would expect to run into is the problem that ld can't
find its crt1.o startup code. This is (usually/sometimes/on occasion)
hardcoded into ld at compile time. ld expects it to be at
<prefix>/lib/crt1.o
Now, suppose you copy your ld executable (and libraries), but leave the old
ones
in place. ld would still search for <prefix>/lib/crt1.o and would not
complain - since it's still there. But this does not mean that you
succesfully relocated the entire toolchain.
Something I picked up from Dan: can you do a
[target-]gcc --print-file-name crt1.o
[target-]gcc --print-file-name specs
and tell us the output? I'd expect it to be printing the prefix'ed path
instead of the copied one. But I could be mistaken.
(another, more conclusive proof would be to remove/rename/backup your
original tree under <prefix>, and repeat the compile steps you performed
earlier)
Regards,
Arno
Information without knowledge is noise
knowledge without wisdom is dangerous stupidity
_________________________________________________________________
MSN Search, for accurate results! http://search.msn.nl
------
Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
More information about the crossgcc
mailing list