Bug 46501 - Relocatable toolchains still search --prefix
Summary: Relocatable toolchains still search --prefix
Status: RESOLVED DUPLICATE of bug 35300
Alias: None
Product: gcc
Classification: Unclassified
Component: driver (show other bugs)
Version: unknown
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL: https://sourceforge.net/tracker/index...
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-16 16:18 UTC by nightstrike
Modified: 2013-08-06 16:59 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description nightstrike 2010-11-16 16:18:01 UTC
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.
Comment 1 Ian Lance Taylor 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.
Comment 2 nightstrike 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.
Comment 3 Joe Turner 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.
Comment 4 nightstrike 2013-04-13 14:51:32 UTC
Adding the two related bugs to See Also, and updating the last reconfirmed date.
Comment 5 LRN 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.
Comment 6 Kai Tietz 2013-08-06 16:59:16 UTC
This bug is a duplicate of pr/35300

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