Ernest L. Williams Jr. wrote:
I would like to relocate a gcc installation to another directory on
another computer but I get the famous:
==========================================================================
gcc: installation problem, cannot exec `cc1': No such file or directory
==========================================================================
Usually this just works, assuming you move the entire installed tree
as a unit without rearranging subdirectories.
[ernesto@lcls-dev2 bin]$ ./powerpc-rtems-gcc -v
Using built-in specs.
Target: powerpc-rtems
Configured with:
/afs/slac/package/rtems/4.7/host/src/gcc-4.0.2//configure
--target=powerpc-rtems --prefix=/afs/slac/package/rtems/4.7/host
--exec-prefix=/afs/slac/package/rtems/4.7/host/i386_linux24
For the last configure option I myself would consult the "Installing
GCC" manual and what this '--exec-prefix='
will cause. As can be seen here, there are TWO different $prefix values
for the toolchain when the default is
only that ONE $prefix given by '--prefix='... But when you used the
'--exec-prefix=', it is assumed that you
really know what it causes to the relocatability! Ok, the rows in
'http://gcc.gnu.org' ("Manual"....) were :
----------------- clip ---------------
The following standard autoconf options are supported. Normally you
should not need to use these options.
|--exec-prefix=|dirname
Specify the toplevel installation directory for
architecture-dependent files. The default is prefix.
----------------- clip ---------------
Maybe only the '--prefix=$prefix' will be used when calculating those
new search paths and the usual :
$new_prefix/libexec/gcc/$target/$gcc_version
will be searched, not your expected :
$new_prefix/i386_linux24/libexec/gcc/$target/$gcc_version
If the '--exec-prefix=$exec_prefix' causes just this... But as was
said, the responsibility is yours when
you used a "normally not needed" feature :(
