Dominic Martinez schreef op vr 11-03-2022 om 15:53 [-0500]:
> Maxime Devos <maximedevos@telenet.be> writes:
> 
> > I doubt that all of these are compile-time tools.  At least most 
> > of
> > them are probably inputs.  (The distinction is important for 
> > cross-
> > compilation.)
> 
> I think I'm confused on how to approach this because Go produces 
> statically linked binaries. A lot of other Go packages also seem 
> to use native-inputs. How does this interact with 
> cross-compilation? All the inputs are used as source libraries 
> here so I'm not sure how to tell if a runtime input is needed.

Static linking is not relevant to inputs/native-inputs -- Guix inputs
don't have a build-time/runtime distinction (*), instead they have a
the-architecture-it-is-being-built-on/the-architecture-it-is-built-for
distinction.  'inputs' = compiled for --target, 'native-inputs' =
compiled for --system.

(*) ignoring complications introduced by propagation.

More concretely, consider the following case:

  * a program A depends on the Go library B
  * the Go library B depends on the C library libfoo (using whatever is
    Go's equivalent of 'dlopen')
  * to avoid things like LD_LIBRARY_PATH, the package definition in
    Guix replaces 'libfoo.so' by '/gnu/store/.../libfoo.so'.
  * the program A is being cross-compiled.

To make sure that the cross-compiled A ends up using the libfoo.so
compiled for --target instead of --system, B has to be in 'inputs'
instead of 'native-inputs'.

This also holds when no .so libraries are used, e.g. if B invokes some
kind of binary with Go's equivalent of 'posix_spawn' and Guix hardcodes
the binary location instead of relying on $PATH.

I haven't tried this for Go packages in particular, but this is how
things work for, say, C and Guile packages.

Greetings,
Maxime.