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
