Toolchain relocation

[Dave Murphy]

Ranjit Mathew wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dave Murphy wrote:
>   
>> I've been having some odd problems with relocation of 4.x toolchains - 
>> i.e. when a toolchain is configured, built and installed with one prefix 
>> but later moved to another location. The binaries appear to be checking 
>> something in the old location before reading from the new path.
>>     
>
> I might be mistaken, but I think this is intentional behaviour.
>   
It may well be, it's certainly been introduced in the 4.x series - 3.x.x 
does not have the issue ( as far back as 3.3.2 anyway)

If I relocate the toolchain on Debian I see the same symptoms with the 
output from -print-search-dirs. I've manually inserted a newline after 
each path here for clarity. Note that install is reported as the 
original configured location, the program paths have 2 extra paths and 7 
are not relocated. For the library paths, no extra paths are added and 3 
are not relocated. I think the issue is only apparent on windows due to 
the request to insert a disk when the original path is removable media.

fairlight:/usr/local/devkitPro# ./devkitARM/bin/arm-elf-gcc 
-print-search-dirs
install:
 /usr/local/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/
programs: =
/usr/local/devkitPro/devkitARM/libexec/gcc/arm-elf/4.1.0/:
/usr/local/devkitPro/devkitARM/libexec/gcc/arm-elf/4.1.0/:
/usr/local/devkitPro/devkitARM/libexec/gcc/arm-elf/:
/usr/local/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/:
/usr/local/devkitPro/devkitARM/lib/gcc/arm-elf/:
/usr/libexec/gcc/arm-elf/4.1.0/:
/usr/libexec/gcc/arm-elf/:
/usr/lib/gcc/arm-elf/4.1.0/:
/usr/lib/gcc/arm-elf/:
/usr/local/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/../../../../arm-elf/bin/arm-elf/4.1.0/:
/usr/local/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/../../../../arm-elf/bin/

libraries: =
/usr/local/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/:
/usr/lib/gcc/arm-elf/4.1.0/:
/usr/local/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib/arm-elf/4.1.0/:
/usr/local/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib/

fairlight:/usr/local/devkitPro# mv devkitARM MOVED

fairlight:/usr/local/devkitPro# ./MOVED/bin/arm-elf-gcc -print-search-dirs
install:
/usr/local/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/

programs: =
/usr/local/devkitPro/MOVED/bin/../libexec/gcc/arm-elf/4.1.0/:
/usr/local/devkitPro/MOVED/bin/../libexec/gcc/:
/usr/local/devkitPro/devkitARM/libexec/gcc/arm-elf/4.1.0/:
/usr/local/devkitPro/devkitARM/libexec/gcc/arm-elf/4.1.0/:
/usr/local/devkitPro/devkitARM/libexec/gcc/arm-elf/:
/usr/local/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/:
/usr/local/devkitPro/devkitARM/lib/gcc/arm-elf/:
/usr/libexec/gcc/arm-elf/4.1.0/:/usr/libexec/gcc/arm-elf/:/usr/lib/gcc/arm-elf/4.1.0/:
/usr/lib/gcc/arm-elf/:
/usr/local/devkitPro/MOVED/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/bin/arm-elf/4.1.0/:
/usr/local/devkitPro/MOVED/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/bin/:
/usr/local/devkitPro/devkitARM/arm-elf/bin/arm-elf/4.1.0/:
/usr/local/devkitPro/devkitARM/arm-elf/bin/

libraries: =
/usr/local/devkitPro/MOVED/bin/../lib/gcc/arm-elf/4.1.0/:
/usr/local/devkitPro/MOVED/bin/../lib/gcc/:
/usr/local/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/:
/usr/lib/gcc/arm-elf/4.1.0/:
/usr/local/devkitPro/MOVED/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib/arm-elf/4.1.0/:
/usr/local/devkitPro/MOVED/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib/:
/usr/local/devkitPro/devkitARM/arm-elf/lib/arm-elf/4.1.0/:
/usr/local/devkitPro/devkitARM/arm-elf/lib/

> FWIW, I have faced a different toolchain relocation problem
> in the GCC 4.1.0 release on MinGW. I configured and built
> GCC using "--prefix=/mingw" on one machine where "/mingw"
> maps to "D:\MiscAppz\MinGW" (I used MSYS as the build environment).
> The compiler built, installed and ran fine on this machine.
>
> However, when I moved the binaries to another machine
> where MinGW was installed in "D:\MinGW", the compiler was
> not able to find the C runtime headers, even though the
> folder structure was exactly the same. 
I think this is due to the compiler believing it was originally 
installed at /mingw when in fact it was really installed at
d:\MiscAppz\Mingw so the relocation of the include directory fails 
because it can't relate the two.

I'm still a little confused by this one because it would seem to 
indicate that the paths to the binaries and libraries are relocated in a 
different manner to the include directories since the relocated compiler 
can find as, ld etc with no trouble.

I know I experience the same problem if I don't configure with 
--prefix=<drive>:/path/to. If I use mount points or the MSYS style 
/<drive>/path/to then the newly built compiler can't find it's include 
directories.
> There was another curious problem with this GCC, even on
> the original machine where it was built: when run from within
> the MSYS environment, everything was hunky-dory but when
> run from the Windows command prompt, it used to give a
> "_spawnvp: No such file or directory" error when one tried
> to compile something.
>   
That's interesting. One of my end users reported a similar problem 
recently but I've been unable to reproduce this locally under win2kpro. 
Was this a win95/98 machine?

In your case I would suspect the original mount point is available 
within MSYS but not from the command prompt where it fails due to the 
disparity between the paths.

Dave