GNU bug report logs - #47869
[PATCH core-updates] ‘which’ looks in PATH, incorrect when cross-compiling

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Maxime Devos <maximedevos <at> telenet.be>
Subject: bug#47869: closed (Re: bug#47869: [PATCH core-updates]
 ‘which’ looks in PATH, incorrect when
 cross-compiling)
Date: Fri, 04 Jun 2021 21:32:01 +0000

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

Your bug report

#47869: [PATCH core-updates] ‘which’ looks in PATH, incorrect when cross-compiling

which was filed against the guix-patches package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 47869 <at> debbugs.gnu.org.

-- 
47869: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=47869
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: 47869-done <at> debbugs.gnu.org
Subject: Re: bug#47869: [PATCH core-updates] ‘which’
 looks in PATH, incorrect when cross-compiling
Date: Fri, 04 Jun 2021 23:31:28 +0200

Hi Maxime,

Maxime Devos <maximedevos <at> telenet.be> skribis:

> This is version 4 of the patch series.
> It lets 'search-input-file' raise the new
> &search-error exception instead of misc-error.
>
> The documentation of 'search-input-file' has been
> adjusted to give an example of how it can be used.
>
> Also, there is one new test in tests/build-utils.scm
> ("search-input-file: can search in multiple directories").

I pushed the whole series as d1827d5c636adb395153a4ed6064629ed5b7664b:

  d1827d5c63 * gnu: wireguard-tools: Set #:sh argument of 'wrap-program'.
  96a2ae40fb * gnu: protonvpn-cli: Set #:sh argument of 'wrap-program'.
  b74085ce36 * gnu: openconnect-sso: Set #:sh argument of 'wrap-program'.
  3bbb0ec888 * gnu: vpnc-scripts: Set #:guile argument of 'wrap-script'.
  a4e38cc216 * gnu: clipmenu: Set #:guile argument of 'wrap-script'.
  0758ee8002 * gnu: sieve-connect: Set #:guile argument of 'wrap-script'.
  b2459387b9 * gnu: nanopolish: Set #:guile argument of 'wrap-script'.
  2d092a2afa * gnu: gess: Set #:guile argument of 'wrap-script'.
  c4989f7569 * gnu: prinseq: Set #:guile argument of 'wrap-script'.
  fadbac0ecc * gnu: proteinortho: Set #:guile argument of 'wrap-script'.
  b202fdf131 * gnu: bats: Set #:guile argument of 'wrap-script'.
  0a843e3643 * gnu: carla: Set #:guile argument of 'wrap-script'.
  a62d17dc05 * rakudo-build-system: Look up the interpreter in 'inputs'.
  2ac898d7f8 * qt-build-system: Look up the interpreter in 'inputs'.
  5b24cbee31 * python-build-system: Look up the interpreter in 'inputs'.
  1dbc3b2b0c * glib-or-gtk-build-system: Look up the interpreter in 'inputs'.
  5378edeab4 * utils: Define ‘search-input-file’ procedure.
  8b0899963f * utils: Allow overriding the shell interpreter in ‘wrap-program’.

Thank you!

Ludo’.

[Message part 3 (message/rfc822, inline)]

From: Maxime Devos <maximedevos <at> telenet.be>
To: guix-patches <at> gnu.org
Subject: [PATCH core-updates] ‘which’ looks in
 PATH, incorrect when cross-compiling
Date: Sun, 18 Apr 2021 13:20:37 +0200

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

The procedure ‘which’ from (guix build utils)
is used for two different purposes:

 1. for finding the absolute file name of a binary
    that we need to run during the build process

 2. for finding the absolute file name of a binary,
    for the target system (as in --target=TARGET),
    e.g. for substituting sh->/gnu/store/.../bin/sh,
    python->/gnu/store/.../bin/python

When compiling natively (SYSTEM=TARGET modulo nix/autotools differences),
this is perfectly fine.

However, when cross-compiling, we have a problem.
"which" looks in $PATH for binaries.  That's good for purpose (1),
but incorrect for (2), as the $PATH contains binaries from native-inputs
instead of inputs.

Admittedly, ‘which’ is simply very convenient (although incorrect
when cross-compiling), and we don't have the right tool ...
until now, that is (see patch)!

This patch adds an optional 'inputs' argument.  When it is present,
'which' will look in the bin and sbin subdirectories of the directories
in the 'inputs' alist.

Use it like this:

  (package [...]
    (arguments
     `(#:modules (guix build utils)
       #:phases
       (modify-phases %standard-phases
         (delete 'configure)
         (delete 'check)
         (add-after 'install 'wrap
           (lambda* (#:key outputs inputs #:allow-other-keys)
             (let ((growpart (string-append (assoc-ref outputs "out")
                                            "/bin/growpart")))
               (wrap-program growpart
                 `("PATH" ":" prefix (,(dirname (which "sfdisk" inputs))
                                      ,(dirname (which "readlink" inputs)))))))))))

(Examples comes from the "cloud-utils" package)
The only change is adding adding the 'inputs' argument.  Isn't that easy?

Alternative methods I've seen:
* (string-append (assoc-ref inputs "coreutils") "/bin/readlink")
* (let ((coreutils (assoc-ref inputs "coreutils")))
    (setenv "PATH" (string-append coreutils "/bin"))
    [code using (which "readlink")])
* (which "readlink") ; possibly incorrect when cross-compiling

I've tested this with "cloud-utils", though admittedly I didn't try to cross-compile
yet, and I've placed my adjusted "which" in a separate module to avoid having to rebuild
everything.  (The attached patch just modifies (guix build utils).)  I've written
a few tests, which pass.  I also documented the new functionality in the manual.

Currently incorrect uses of "which" can be fixed in a follow-up patch.

Thoughts?
Maxime.

[0001-build-Add-argument-to-which-for-specifying-where-to-.patch (text/x-patch, attachment)]

[0002-doc-Document-new-functionality-of-which.patch (text/x-patch, attachment)]

[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.