bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#54728: [PATCH 2/2] gnu: valgrind: fix ld.so symbols not found


From: Denis 'GNUtoo' Carikli
Subject: bug#54728: [PATCH 2/2] gnu: valgrind: fix ld.so symbols not found
Date: Mon, 25 Apr 2022 18:39:09 +0200

On Fri, 15 Apr 2022 18:21:33 +0200
Ludovic Courtès <ludo@gnu.org> wrote:
> Hello!
Hi,

[...]
> I find this patch-as-code snippet rather difficult to follow; it might
> also break easily if minor things change in those C files.
> 
> How about making it an actual patch?  In the patch, you’d have
> placeholders for the store file names, like @LIBC_DEBUG_DIRECTORY@;
> the phase would replace those placeholders with ‘substitute*’.
Thanks, I've done that and now the code is much easier to read.

> Rather: ("libc:debug" ,(canonical-package glibc) "debug").
The issue with that is that importing "gnu packages commencement" fails
with the following error:
> $ ./pre-inst-env guix build hello
> error: tcc: unbound variable
> hint: Did you forget a `use-modules' form?
> 
> error: googletest: unbound variable
> hint: Did you forget a `use-modules' form?
> 
> error: bzip2: unbound variable
> hint: Did you forget a `use-modules' form?
> 
> error: binutils: unbound variable
> hint: Did you forget a `use-modules' form?
> 
> error: gcc-4.9: unbound variable
> hint: Did you forget a `use-modules' form?
> 
> error: xz: unbound variable
> hint: Did you forget a `use-modules' form?
> 
> error: gnu-make: unbound variable
> hint: Did you forget a `use-modules' form?
> 
> error: binutils: unbound variable
> hint: Did you forget a `use-modules' form?
> 
> error: perl: unbound variable
> hint: Did you forget a `use-modules' form?
> 
> error: coreutils: unbound variable
> hint: Did you forget a `use-modules' form?
> 
> Throw to key `unbound-variable' with args `("resolve-interface" "no
> binding `~A' in module ~A" (python (gnu packages python)) #f)'.
> Backtrace: In guix/store.scm:
>    658:37 19 (thunk)
>    1320:8 18 (call-with-build-handler #<procedure 995c6f0 at guix/u?>
> ?) In guix/scripts/build.scm:
>     499:2 17 (_)
> In srfi/srfi-1.scm:
>    673:15 16 (append-map _ _ . _)
>    586:17 15 (map1 ((argument . "hello") (build-mode . 0) (# . #t) ?))
> In guix/scripts/build.scm:
>    519:31 14 (_ _)
> In gnu/packages.scm:
>     480:2 13 (%find-package "hello" "hello" #f)
>     365:6 12 (find-best-packages-by-name _ _)
>    295:56 11 (_ "hello" _)
> In unknown file:
>           10 (force #<promise #<procedure 9a81870 at
> gnu/packages.sc?>) In gnu/packages.scm:
>    242:33  9 (fold-packages #<procedure b45e1e78 at gnu/packages.sc?>
> ?) In guix/discovery.scm:
>    159:11  8 (all-modules _ #:warn _)
> In srfi/srfi-1.scm:
>    460:18  7 (fold #<procedure 9814390 at guix/discovery.scm:143:8 ?>
> ?) In guix/discovery.scm:
>    149:19  6 (_ _ ())
>     116:5  5 (scheme-modules _ _ #:warn _)
> In srfi/srfi-1.scm:
>    691:23  4 (filter-map #<procedure 98142e0 at guix/discovery.sc?> .
> #) In guix/discovery.scm:
>    124:24  3 (_ . _)
> In guix/ui.scm:
>     319:2  2 (report-unbound-variable-error _ #:frame _)
> In ice-9/boot-9.scm:
>   1685:16  1 (raise-exception _ #:continuable? _)
>   1685:16  0 (raise-exception _ #:continuable? _)
> 
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Throw to key `match-error' with args `("match" "no matching pattern"
> (unbound-variable "resolve-interface" "no binding `~A' in module ~A"
> (python (gnu packages python)) #f))'.
So I need to not import gnu packages commencement globally.

I can also do something like that instead: 
> ("glibc:debug"
>     ,((@@ (gnu packages commencement) canonical-package)
>        (@@ (gnu packages commencement) glibc)) "debug")

Which form is the best?

Beside the glibc:debug input, the new patch is ready to be sent. I also
successfully managed to run tests that use valgrind transparently (by
using valgrind/interactive in the native inputs).

Denis.

Attachment: pgpqeA4Dc0QTZ.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]