GNU bug report logs - #55449
recutils cross-compilation "fix" breaks bash builtins

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 55449 in the body.
You can then email your comments to 55449 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>
To: bug-guix <at> gnu.org
Cc: Tobias Geerinckx-Rice <me <at> tobias.gr>
Subject: recutils cross-compilation "fix" breaks bash builtins
Date: Mon, 16 May 2022 14:52:00 +0200

Hi Guix,

The fix in commit 20fbd870938e239c038d8524a56729f123f19f80, which lets
recutils cross-compile unfortunately omits support for the bash
builtins in all build modes, as recutils can't actually detect bash
headers there.

Unfortunately, recutils' configure.ac silently swallows this error in
the following check.
  AM_CONDITIONAL([BASH_BUILTINS],
                 [test "x$bash_headers_available" = "xyes" && 
                  test "x$bash_builtins_enabled" = "xyes"])
I only noticed, because I symlink the builtins to lib/bash, where
they're actually needed, which causes runpath validation to fail
because the symlink points to a file that doesn't exist.  I fixed this
locally, but still wanted y'all to know.

Is there a way we can support bash headers in cross-compilation
contexts?  I don't think having bash:include as a native input is even
helpful here, is it?  WDYT?

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

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>, bug-guix <at> gnu.org
Subject: Re: recutils cross-compilation "fix" breaks bash builtins
Date: Mon, 16 May 2022 13:37:34 +0000

Yeah, I toyed with the idea of a 'assert-readrec-existence phase but it seemed a bit silly at the time.  And look, now it vanished.

Headers being a native input looked and still looks hella sus to me, but presumably done for a reason...?  (They said, optimistically.)

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

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

From: Maxime Devos <maximedevos <at> telenet.be>
To: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>, 
 55449 <at> debbugs.gnu.org
Cc: Tobias Geerinckx-Rice <me <at> tobias.gr>
Subject: Re: bug#55449: recutils cross-compilation "fix" breaks bash builtins
Date: Mon, 16 May 2022 17:15:03 +0200

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

Liliana Marie Prikler schreef op ma 16-05-2022 om 14:52 [+0200]:
> Is there a way we can support bash headers in cross-compilation
> contexts?  I don't think having bash:include as a native input is even
> helpful here, is it?  WDYT?
> 
> 


Maybe you can give <https://issues.guix.gnu.org/55377> a try ... needs
a rebase though.  No idea if it helps here.

Greetings,
Maxime.

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

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

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: 55449 <at> debbugs.gnu.org
Cc: Tobias Geerinckx-Rice <me <at> tobias.gr>, Maxime Devos <maximedevos <at> telenet.be>
Subject: [PATCH] gnu: recutils: Use correct bash headers.
Date: Sat, 4 Jun 2022 10:30:12 +0200

* gnu/packages/databases.scm (recutils)[arguments]: Convert to G-Expressions.
Drop gratuitous dirname.
[native-inputs]: Drop labels.  Move bash:include...
[inputs]: ... here.  Also add regular bash.
---
 gnu/packages/databases.scm | 19 ++++++++-----------
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scm
index 09d825af3e..5cd8cc2fa3 100644
--- a/gnu/packages/databases.scm
+++ b/gnu/packages/databases.scm
@@ -1527,20 +1527,17 @@ (define-public recutils
     (build-system gnu-build-system)
     (arguments
      (list #:configure-flags
-           '(list "--disable-static"
-                  (string-append "--with-bash-headers="
-                                 (dirname (search-input-directory
-                                           %build-inputs
-                                           "include/bash"))))))
+           #~(list "--disable-static"
+                   (string-append "--with-bash-headers="
+                                  (search-input-directory %build-inputs
+                                                          "include/bash")))))
     (native-inputs
-     ;; XXX Without labels, the default 'configure phase picks the wrong "bash".
-     `(("bc" ,bc)
-       ("bash:include" ,bash "include")
-       ("check" ,check-0.14)
-       ("pkg-config" ,pkg-config)))
+     (list bc check-0.14 pkg-config))
     (inputs
      ;; TODO: Add more optional inputs.
-     (list curl
+     (list bash                         ; /bin/bash for native compilation
+           `(,bash "include")
+           curl
            libgcrypt
            `(,util-linux "lib")))
     (synopsis "Manipulate plain text files as databases")
-- 
2.36.1

Message #19 received at 55449-done <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: 55449-done <at> debbugs.gnu.org
Cc: Tobias Geerinckx-Rice <me <at> tobias.gr>, Maxime Devos <maximedevos <at> telenet.be>
Subject: Re: [PATCH] gnu: recutils: Use correct bash headers.
Date: Sun, 18 Jun 2023 09:39:34 +0200

Am Samstag, dem 04.06.2022 um 10:30 +0200 schrieb Liliana Marie
Prikler:
> * gnu/packages/databases.scm (recutils)[arguments]: Convert to G-
> Expressions.
> Drop gratuitous dirname.
> [native-inputs]: Drop labels.  Move bash:include...
> [inputs]: ... here.  Also add regular bash.
> ---
Hi Guix, I've pushed this now.

There's still a UX issue in that recutils doesn't put these libraries
into lib/bash, but at the very least it works as described in the
manual right now.

Cheers

Previous Next

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