[Bug driver/46501] New: Relocatable toolchains still search --prefix

[Bug driver/46501] New: Relocatable toolchains still search --prefix

[nightstrike at gmail dot com]

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: unassigned@gcc.gnu.org
        ReportedBy: nightstrike@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.

[Bug driver/46501] Relocatable toolchains still search --prefix

[ian at airs dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46501

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian at airs dot com

--- Comment #1 from Ian Lance Taylor <ian at airs dot com> 2010-11-16 17:33:19 UTC ---
If at all possible, please list the precise cases where the value passed to
--prefix appears in a search path incorrectly.  Please indicate precisely how
gcc was configured, precisely how gcc was installed, and which incorrect search
path was used.

Without that information, any fix that we make is unlikely to actually fix your
problem, as you are probably doing something which we will inadvertently fail
to test.

Thanks.

[Bug driver/46501] Relocatable toolchains still search --prefix

[nightstrike at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46501

--- Comment #2 from nightstrike <nightstrike at gmail dot com> 2010-11-16 17:48:32 UTC ---
Configure:
../../../build/gcc/src/configure \
    --target=i686-w64-mingw32 \
     \
    --prefix=/buildbot/mingw-w64/linux-x86_64-x86/build/build/root \
    --with-sysroot=/buildbot/mingw-w64/linux-x86_64-x86/build/build/root \
    --enable-languages=all,obj-c++ \
    --enable-fully-dynamic-string --disable-multilib


Build toolchain, install to $prefix.

cd $prefix && tar cjf a.tbz2 * (or similar)
cd /usr && tar xjf a.tbz2 (or equivalent)


So what we are doing is essentially building a "relocatable" toolchain,
installing it to some location, tarring up that location, and then extracting
it wherever we want.  The user referenced in the URL attached this PR wanted to
extract it to /usr (thus causing the issue of the embedded directory "root"),
but the eventual location you extract to doesn't affect the inclusion of
directories outside of the gcc hierarchy.  Observe:


i686-w64-mingw32-gcc -print-search-dirs:

install: /usr/bin/../lib/gcc/i686-w64-mingw32/4.6.0/ programs:
=/usr/bin/../libexec/gcc/i686-w64-mingw32/4.6.0/:/usr/bin/../libexec/gcc/:/usr/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/bin/i686-w64-mingw32/4.6.0/:/usr/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/bin/
libraries:
=/usr/bin/../lib/gcc/i686-w64-mingw32/4.6.0/:/usr/bin/../lib/gcc/:/usr/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/lib/i686-w64-mingw32/4.6.0/:/usr/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/lib/../lib/:/usr/bin/../../root/mingw/lib/i686-w64-mingw32/4.6.0/:/usr/bin/../../root/mingw/lib/../lib/:/usr/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/lib/:/usr/bin/../../root/mingw/lib/


You can see in there where there are references to "root".  These are what are
incorrect.

Please let me know if that is enough information for you.

[Bug driver/46501] Relocatable toolchains still search --prefix

[joe at oampo dot co.uk]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46501

Joe Turner <joe at oampo dot co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |joe at oampo dot co.uk

--- Comment #3 from Joe Turner <joe at oampo dot co.uk> 2013-04-04 16:03:46 UTC ---
A quick note to confirm that this is still a problem.  It just caught me out
when building in a subfolder of my home directory, and relocating the build to
a server where access to /home is restricted.  This caused the compiler to
throw permission denied errors when searching the --prefix path.

[Bug driver/46501] Relocatable toolchains still search --prefix

[nightstrike at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46501

nightstrike <nightstrike at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |http://gcc.gnu.org/bugzilla
                   |                            |/show_bug.cgi?id=17621,
                   |                            |http://gcc.gnu.org/bugzilla
                   |                            |/show_bug.cgi?id=35300

--- Comment #4 from nightstrike <nightstrike at gmail dot com> 2013-04-13 14:51:32 UTC ---
Adding the two related bugs to See Also, and updating the last reconfirmed
date.

[Bug driver/46501] Relocatable toolchains still search --prefix

[lrn1986 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46501

LRN <lrn1986 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lrn1986 at gmail dot com

--- Comment #5 from LRN <lrn1986 at gmail dot com> 2013-04-13 15:31:21 UTC ---
A gcc toolchain built on W32 for W32 (using MSys shell and make to run the
buildsystem) also suffers from this. In all and any mingw builds (except for
TDM's, they are patched somehow) that are built with --prefix=/mingw, the
directory "/mingw/include" ends up in cpp_include_defaults list, and
"/mingw/lib" - in the list that -print-search-dirs outputs for libraries.

W32 interprets "/mingw" as "mingw subdirectory in the root directory of the
drive on which current working directory is", so having headers in
"c:/mingw/include", "d:/mingw/include", ... etc (and libraries in
"c:/mingw/lib", ... etc) was, and is, strongly advised against by all
gcc-for-w32 toolchain suppliers for _years_. Which likely means that this issue
is old.

[Bug driver/46501] Relocatable toolchains still search --prefix

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46501

Kai Tietz <ktietz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #6 from Kai Tietz <ktietz at gcc dot gnu.org> ---
This bug is a duplicate of pr/35300

*** This bug has been marked as a duplicate of bug 35300 ***