Re: relocating the compiler and associated tools

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

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