Re: 'guix build [P]' followed by 'guix install /gnu/store/[...]' vs. 'guix install [P]'

[Thomas Schwinge <tschwinge@baylibre.com>]

Hi Ludo!

On 2024-11-10T00:31:12+0100, Ludovic Courtès <ludo@gnu.org> wrote:
> Thomas Schwinge <tschwinge@baylibre.com> skribis:
>
>>>     $ guix install -p bi /gnu/store/lahbqdidl3ynasd0vzxz2i0dmgh0v16i-gcc-toolchain-4.8.5
>>>     [...]
>>>
>>> ..., where '/gnu/store/[...]-gcc-toolchain-4.8.5' is the main ("out")
>>> output, which should -- per my understanding -- correspond to directly
>>> 'guix install'ing:
>>>
>>>     $ guix install -p i gcc-toolchain@4.8.5
>>>     [...]
>>>
>>> But now compare the two installations:
>>>
>>>     $ diff -ru bi/ i/
>
> [...]
>
>>>     --- bi/manifest 1970-01-01 01:00:01.000000000 +0100
>>>     +++ i/manifest  1970-01-01 01:00:01.000000000 +0100
>>>     @@ -9,4 +9,40 @@
>>>          (("gcc-toolchain"
>>>            "4.8.5"
>>>            "out"
>>>     -      "/gnu/store/lahbqdidl3ynasd0vzxz2i0dmgh0v16i-gcc-toolchain-4.8.5"))))
>>>     +      "/gnu/store/lahbqdidl3ynasd0vzxz2i0dmgh0v16i-gcc-toolchain-4.8.5"
>>>     +      (search-paths
>>>     +        (("C_INCLUDE_PATH" ("include") ":" directory #f)
>>>     +         ("CPLUS_INCLUDE_PATH"
>>>     +          ("include/c++" "include")
>>>     +          ":"
>>>     +          directory
>>>     +          #f)
>
> [...]
>
>>> This means that the 'bi' installation isn't usable.
>
> This may sound surprising but it’s expected.
>
> The reason is that when you run:
>
>   guix install gcc-toolchain
>
> ‘gcc-toolchain’ is a live package with metadata that Guix uses when it
> builds the profile, in particular data about search paths.
>
> However, when you run:
>
>   guix package -i /gnu/store/…
>
> then all Guix sees is an inert store item with no associated metadata.
> This is why it ends up creating a profile without search path info.

Hmm, I see.  That also matches what Rutherther had written on IRC.
However, conceptually, I don't understand the rationale for doing it this
way.  Isn't this Guix use of 'C_INCLUDE_PATH' etc. intimately specific to
the way how GCC has to be built/used in the Guix context?  Therefore, I'd
expect such setup code to be an artifact (meta data) of 'guix build',
that is, written into '/gnu/store/[...]-gcc-toolchain-4.8.5/etc/profile'
at 'guix build' time, instead of into the '[Guix profile]/etc/profile'
created by 'guix install', and 'guix install' would then just use that
file (like, add to the '[Guix profile]/etc/profile' a shell
'source /gnu/store/[...]-gcc-toolchain-4.8.5/etc/profile').

But, of course, I'm still very new with learning Guix concepts and
implementation, so...  ;-|

> This is one of the reasons why I would recommend against that second
> method.  It might be useful as a last resort but should be avoided as
> much as possible.

Hmm.  But is it really a good idea then at all, to offer this way of
'guix install'ing packages, if it can't be expected to work reliably?


What is then the proper Guix way to achieve the following:

| All this came up in context of wanting to install '--system=i686-linux'
| packages on '--system=x86_64-linux', and I'm not able to just
| 'guix install --system=i686-linux gcc-toolchain@4.8.5' there.
|
| (Is there a fundamental reason for not allowing that, or just not yet
| implemented?)


> (For development, I’d also recommend ‘guix shell’ over ‘guix install’!)

That's also what yelninei suggested on IRC.  I'm aware of 'guix shell',
and 'guix shell --system=i686-linux [...]' does work as expected, but
that's not feasible as an interactive shell if you'd like to use Guix GCC
to build upstream GCC: see <https://debbugs.gnu.org/72669>
"gcc-toolchain environment variables", for example.  I could have wrapper
'gcc' etc. scripts that internally do:

    guix shell --system=i686-linux gcc-toolchain@4.8.5 -- gcc "$@"

..., but I'm not sure about the overhead of all those hundreds of
'guix shell [...]' invocations?


I'm happy to continue the discussion; hopefully with my GCC/toolchain
experience I can eventually make a useful contribution to Guix here?
(Unless, of course, I get convinced that the status quo is already the
right way...)  ;-)


Grüße
 Thomas