public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Keith Packard <keithp@keithp.com>
To: gcc-patches@gcc.gnu.org
Subject: Making gcc toolchain installs relocatable
Date: Fri, 23 Sep 2022 11:40:51 -0700	[thread overview]
Message-ID: <877d1ux7bg.fsf@keithp.com> (raw)
In-Reply-To: <20220827051422.1023580-1-keithp@keithp.com>

[-- Attachment #1: Type: text/plain, Size: 1988 bytes --]


I submitted the referenced patch to extend the 'getenv' .specs function
back in August and didn't see any response, so I wanted to provide a bit
more context to see if that would help people understand why I wrote
this.

Here's a link to that message:

        https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600452.html

I'm working with embedded toolchains where I want to distribute binary
versions of binutils, gcc and a suite of libraries in a tar file which
the user can unpack anywhere on their system. To make this work, I need
to create .spec file fragments that can locate the correct libraries
relative to the location where the toolchain was unpacked.

An easy way to do this, which doesn't depend on a default sysroot value,
is to use the GCC_EXEC_PREFIX environment variable in the .specs
file. Gcc sets that whenever it discovers that it hasn't been run from
the defined installation path. However, if the user does end up
installing gcc in the defined installation path, then that variable
isn't set at all. If a .specs file attempts to reference the variable,
gcc will emit a fatal error and exit.

This patch makes it possible for the .specs file fragment to provide the
default path as a fallback for a missing environment variable so that,
instead of exiting, the correct value will be substituted instead.

By doing this, I can create portable .specs file fragments which work
wherever the toolchain is installed.

This patch seemed like the least invasive approach to solving this
problem, but there are two other approaches that could work, and which
would make the .specs files simpler:

 1. Always set the GCC_EXEC_PREFIX environment variable, even if GCC
    is executed from the expected location.

 2. Make %R in .specs files expand to the appropriate value even if
    there is no sysroot defined.

I'd be happy to provide an implementation of either of those if that
would be more acceptable.

-- 
-keith

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  parent reply	other threads:[~2022-09-23 18:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-27  5:14 [PATCH] driver: Extend 'getenv' function to allow default value Keith Packard
2022-08-27  5:14 ` Keith Packard
2022-09-23 18:40 ` Keith Packard [this message]
2022-11-20 18:34   ` Making gcc toolchain installs relocatable Jeff Law

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=877d1ux7bg.fsf@keithp.com \
    --to=keithp@keithp.com \
    --cc=gcc-patches@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).