Re: Making gcc toolchain installs relocatable

2022-11-20 Thread Jeff Law via Gcc-patches



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





Making gcc toolchain installs relocatable

2022-09-23 Thread Keith Packard via Gcc-patches

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


signature.asc
Description: PGP signature