public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "nightstrike at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug driver/46501] New: Relocatable toolchains still search --prefix
Date: Tue, 16 Nov 2010 16:20:00 -0000	[thread overview]
Message-ID: <bug-46501-4@http.gcc.gnu.org/bugzilla/> (raw)

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.


             reply	other threads:[~2010-11-16 16:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-16 16:20 nightstrike at gmail dot com [this message]
2010-11-16 17:36 ` [Bug driver/46501] " ian at airs dot com
2010-11-16 17:57 ` nightstrike at gmail dot com
2013-04-04 16:03 ` joe at oampo dot co.uk
2013-04-13 14:51 ` nightstrike at gmail dot com
2013-04-13 15:31 ` lrn1986 at gmail dot com
2013-08-06 16:59 ` ktietz at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-46501-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).