http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46501
Summary: Relocatable toolchains still search --prefix
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nightstr...@gmail.com
See related bugs:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35300
Creating a relocatable toolchain allows a person to build a toolchain, install
it anywhere, and then move that toolchain to any location and still have the
various compilers find all of their pieces.
This doesn't always work, however.
The value of --prefix passed to configure winds up making its way into the
search paths, which has been causing some weird issues. We do this by setting
prefix equal to with-sysroot, which is a legal way of building a relocatable
toolchain. Doing so, however, forces gcc to look in relative paths outside of
the directory tree where gcc resides.
Initially, we were compiling on windows hosts with a prefix set to G:\. This
resulted in unusual error messages when that toolchain was used on machines
with drive G: set to a removable disk drive with nothing in it. We solved that
by just not using a G:\ prefix, and instead mounting that partition in the C:\
hierarchy (since C:\ is pretty much guaranteed to exist on a Windows platform).
The issue reared its head again when a user tried moving one of our cross
compilers into /usr. We use the moniker "root" for the top level of the
installation prefix (for instance, ../configure --prefix=something/root). This
then caused gcc to look in /usr/bin/../../root for its additional programs.
That directory usually exists on linux systems, and it's usually only
accessible by the root user. That causes obvious problems, with a kludgey
workaround being to just move the toolchain to /usr/local.
And yes, that works. But it masks the actual problem, which is that gcc should
not be looking at anything outside of its own directory structure when compiled
in "relocatable" mode.
