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.
next 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: linkBe 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).