GNU bug report logs - #54335
[PATCH 00/14] gnu: Add nebula.

Previous Next

Full log

Message #143 received at 54335 <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: Dominic Martinez <dom <at> dominicm.dev>
Cc: 54335 <at> debbugs.gnu.org
Subject: Re: [bug#54335] [PATCH 14/14] gnu: Add nebula.
Date: Sat, 12 Mar 2022 23:20:56 +0100

[Message part 1 (text/plain, inline)]

Dominic Martinez schreef op vr 11-03-2022 om 15:53 [-0500]:
> Maxime Devos <maximedevos <at> 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.

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.