From: Jeff Law <jeffreyalaw@gmail.com>
To: Keith Packard <keithp@keithp.com>, gcc-patches@gcc.gnu.org
Subject: Re: Making gcc toolchain installs relocatable
Date: Sun, 20 Nov 2022 11:34:51 -0700 [thread overview]
Message-ID: <7d2ef3bc-a4bc-90a9-14bc-2974488f0f8c@gmail.com> (raw)
In-Reply-To: <877d1ux7bg.fsf@keithp.com>
On 9/23/22 12:40, Keith Packard via Gcc-patches wrote:
> 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.
I think most folks generally loathe getting into specs and such. So as
one of the reviewers of last resort, I'll see what I can do here.
So we already have a goodly amount of infrastructure for relocateable
toolchains and relocateable sysroots. So the natural question that
arises is what is it about your environment that is different and
prevents those existing mechanisms from working.
>
> 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.
So the first half of that paragraph describes what I do all the time.
I've got cross toolchain (gcc, binutils, various libraries & headers).
Those all go into a sysroot and I can relocate the toolchain to anywhere
in the filesystem and it "just works". I do this for both bare metal
tooclhains using newlib as well as linux-gnu toolchains using glibc.
Now you mention you need to create .spec file fragments to locate the
correct libraries. But if the libraries are in the sysroot, then you
shouldn't really need to do anything special. Drop them into the right
place and they should relocate just like glibc, newlib, etc.
So maybe the problem is you're not using sysroots?
>
> 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
Are you not using sysroots at all? If so, why not?
> 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 is a good hint. Have you considered building with a sysroot like
/wontexist, installing everything into there, then moving the whole
thing to a more sensible directory before tarring it up?
What's useful about that is you always have a sysroot defined, but it
generally won't exist at runtime. so GCC_EXEC_PREFIX should always be
set and everything should "just work" from that point onward.
Jeff
prev parent reply other threads:[~2022-11-20 18:34 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 ` Making gcc toolchain installs relocatable Keith Packard
2022-11-20 18:34 ` Jeff Law [this message]
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=7d2ef3bc-a4bc-90a9-14bc-2974488f0f8c@gmail.com \
--to=jeffreyalaw@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=keithp@keithp.com \
/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).