bug#63666: sporadic “guix substitute: error: connect*: Connection timed out”
Simon Tournier skribis: > On mer., 24 mai 2023 at 17:01, Ludovic Courtès wrote: > >>> gumbo-parser-0.10.1 149KiB >>> >>>555KiB/s 00:00 >>> ▕██▏ 100.0% >>> cups-minimal-2.4.2 4.9MiB >>> >>>533KiB/s 00:03 ▕█▎ >>> ▏ 29.2%guix substitute: warning: while fetching >>> https://ci.guix.gnu.org/nar/lzip/mcdi162f45smrgvjmm3vldx2i1xhz0x5-iso-codes-4.5.0: >>> server is somewhat slow >>> guix substitute: warning: try `--no-substitutes' if the problem persists >>> retrying download of >>> '/gnu/store/mcdi162f45smrgvjmm3vldx2i1xhz0x5-iso-codes-4.5.0' with other >>> substitute URLs... >> >> Good, that’s the expected behavior. (Of course that may still fail if >> there are no other valid substitute URLs.) > > Well, I do not have other substitutes and sometimes it displays this > message but it does not fail. Does it retry? The warning is just that: a warning. It’s telling you that the thing is slow. In the case above, on top of being slow, something went wrong, which is why it tried again with another URL. >>> No more progress bars. >> >> That’s because you have max-jobs > 1: progress bars aren’t displayed >> when several jobs are running in parallel. > > Well, I only see this “substitution of …” message when before the > progress bar is broken by a warning. Then I do not see again any > progress bar. Hmm interesting. I wouldn’t think the progress bar can be “broken” by the warning, but maybe there’s something fishy going on that leads (guix status) to think one of the substitution jobs never finished, which is why it falls back to no-progress-bar behavior. Thanks, Ludo’.
bug#63238: issue linking to librt
librt and libpthread were merged into libc with glibc 2.34, however, for compatibility, there exist empty .a files to satisfy the linker. But because Guix has a separate output for the static libraries, they need to be explicitly installed from ‘glibc:static’, which allows Cargo to do its thing. Cargo itself should probably be fixed so that it no longer tries to link with these libraries, but until that time, the above work-around suffices.
bug#63728: GHC cannot find lrt
Mekeor Melire writes: > 2023-05-25 22:25 bug-guix@gnu.org: > >> Attempting to build a trivial Haskell program using ghc fails, as the linker >> cannot find the rt library: > > Does installing gcc-toolchain:static help as a work-around? I merged this bug with #63258. The gcc-toolchain:static workaround fixes the rt problem, but now the binaries aren't linked to libgmp and libffi, even though gmp and libffi packages are installed in the profile: --8<---cut here---start->8--- ~$ ghc -O2 test.hs ~$ ldd ./test linux-vdso.so.1 (0x7ffe0956f000) libgmp.so.10 => not found libc.so.6 => /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libc.so.6 (0x7fbe27e3f000) libm.so.6 => /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libm.so.6 (0x7fbe27d62000) libffi.so.8 => not found libgcc_s.so.1 => /gnu/store/qcg59v4yg239jj1k0xvqqqkqv6l8q6ll-gcc-12.2.0-lib/lib/libgcc_s.so.1 (0x7fbe27d41000) /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/ld-linux-x86-64.so.2 => /gnu/store/ip9mj1pwymxi1yq32zbhwp3n3bycy6yi-glibc-2.35/lib/ld-linux-x86-64.so.2 (0x7fbe2803d000) --8<---cut here---end--->8--- Maybe there should be a ghc-toolchain package that has libgmp and libffi as inputs, and makes sure GHC links them correctly?
bug#63728: (no subject)
merge 63258 63728
bug#63738: [PATCH glibc] Stop checking if MiG supports retcode.
Hey guix people! The Hurd developers having a 64 bit Hurd that can run
/bin/sh. The below are some tips for how to set up such a thing if you
were so inclined. The Debian people are providing 64-bit hurd
applications here for now:
https://people.debian.org/~sthibault/tmp/hurd-amd64
Flávio Cruz writes:
> Hi Sergey
>
> On Fri, May 19, 2023 at 4:02 AM Sergey Bugaev wrote:
>
> Hi,
>
> On Fri, May 19, 2023 at 9:43 AM Flávio Cruz
> wrote:
> > I have made changes so that it does daily builds and I'm able to boot
> small programs. However, I haven't had the time to boot programs built
> against Glibc. How do you package and boot the static binaries using a
> ramdisk? I've been reading the other threads about the Guix/rumpkernel
> so I might be able to piece something together and try it this weekend.
>
> You just put the entirety of the root filesystem (containing /usr,
> /bin, /lib, /hurd, and so on) as an ext2 image into a *file* that you
> place onto the actual drive (a CD disk in my case), and then you ask
> GRUB to load the file from the drive into memory, tell gnumach to make
> a ramdisk device out of it (you'll need to apply [0]), and tell ext2fs
> to use that device. Here's the relevant piece of my grub config
> script:
>
> [0]:
>
> https://salsa.debian.org/hurd-team/gnumach/-/blob/master/debian/patches/50_initrd.patch
>
>
> multiboot /boot/gnumach console=com0
> module /boot/initrd.ext2 initrd.ext2 '$(ramdisk-create)'
> module /sbin/ext2fs.static ext2fs
> --multiboot-command-line='${kernel-command-line}' --readonly
> --host-priv-port='${host-port}' --device-master-port='${device-port}'
> --exec-server-task='${exec-task}' --kernel-task='${kernel-task}' -T
> device rd0 '$(fs-task=task-create)' '$(prompt-task-resume)'
> module /lib/ld.so.1 ld.so.1 /hurd/exec
> --device-master-port='${device-port}' '$(exec-task=task-create)'
> boot
>
> (I should probably change it to not hardcode 'rd0', but whatever).
> Note that /boot/gnumach, /boot/initrd.ext2, /sbin/ext2fs.static, and
> /lib/ld.so.1 are all paths inside the CD image (those are going to be
> loaded by GRUB), and /boot/initrd.ext2 is the ext2 filesystem image
> containing the actual Hurd root. /hurd/exec however is already a path
> inside the fs image -- this is where ld.so (not grub) is going to load
> the exec server from. The only static binary here is ext2fs.static,
> the rest are all dynamically linked.
>
> Then in /libexec/console-run (inside the filesystem image), I have
> written the following:
>
> #! /bin/sh
>
> settrans -ac /dev/mach-console /hurd/streamio console
> exec <>/dev/mach-console >&0 2>&0
> echo Hello from /bin/sh!
> exec /bin/sh -i
>
> (If you're going to do the same, don't forget to create the
> /dev/mach-console node beforehand, since the fs is read-only.) I also
> had to patch streamio a little to do the \r -> \n conversion like
> glibc already does in devstream:
>
> diff --git a/trans/streamio.c b/trans/streamio.c
> index 272a002c..0af1aea3 100644
> --- a/trans/streamio.c
> +++ b/trans/streamio.c
> @@ -500,6 +500,9 @@ trivfs_S_io_read (struct trivfs_protid *cred,
>cred->po->openmodes & O_NONBLOCK);
> pthread_mutex_unlock (_lock);
> *data_len = data_size;
> + for (size_t i = 0; i < data_size; i++)
> +if ((*data)[i] == '\r')
> + (*data)[i] = '\n';
> return err;
> }
>
> (maybe I should also add echoing of input characters in the same way,
> which is also what glibc's devstream does -- otherwise currently I
> don't see what I'm typing on the console).
>
> Make sure to use the very latest glibc (Samuel has already pushed all
> of my patches upstream!) + the BRK_START hack.
>
> Thanks for the instructions. I was able to make it work and pushed my
> changes to Github.
>
> For people that might want to try out the new port using
> https://github.com/flavioc/cross-hurd,
> the following will download the packages and build a disk image with the ram
> disk:
>
> $ export CPU=x86_64
> $ bash download.sh && bash bootstrap.sh && bash compile.sh && bash
> create-initrd.sh
>
> Then, to run qemu:
>
> $ bash start-qemu-debug.sh
>
> Sergey
>
--
Joshua Branson
Sent from the Hurd
bug#63736: [Shepherd] Loss of SIGCHLD notifications
I experienced, with the Shepherd 0.10.0, a situation where ‘herd
restart’ would get stuck after the end-of-grace-period expiration
(restarting nscd in this case):
--8<---cut here---start->8---
May 26 08:44:33 localhost shepherd[1]: [NetworkManager] Status of nscd:
May 26 08:44:33 localhost shepherd[1]: [NetworkManager] It is running since
08:43:57 (36 seconds ago).
May 26 08:44:33 localhost shepherd[1]: [NetworkManager] Running value is
23753.
May 26 08:44:33 localhost shepherd[1]: [NetworkManager] It is enabled.
May 26 08:44:33 localhost shepherd[1]: [NetworkManager] Provides (nscd).
May 26 08:44:33 localhost shepherd[1]: [NetworkManager] Requires
(user-processes syslogd).
May 26 08:44:33 localhost shepherd[1]: [NetworkManager] Will be respawned.
May 26 08:44:33 localhost shepherd[1]: Stopping service nscd...
[...]
May 26 08:44:38 localhost shepherd[1]: Grace period of 5 seconds is over;
sending -23753 SIGKILL.
--8<---cut here---end--->8---
The ‘herd restart’ process is indeed waiting, and the nscd process is
still around as zombie, meaning that shepherd didn’t call waitpid(2):
--8<---cut here---start->8---
$ sudo herd status nscd
Status of nscd:
It is being stopped.
It is enabled.
Provides (nscd).
Requires (user-processes syslogd).
Will be respawned.
$ ps aux|grep nscd
root 23753 0.0 0.0 0 0 ?Zs 08:43 0:00 [nscd]
root 23870 0.0 0.1 49968 18088 ?Sl 08:44 0:00
/gnu/store/4gvgcfdiz67wv04ihqfa8pqwzsb0qpv5-guile-3.0.9/bin/guile
--no-auto-compile /run/current-system/profile/bin/herd restart nscd
ludo 25280 33.3 0.0 6112 2304 pts/0S+ 09:32 0:00 grep
--color=auto nscd
--8<---cut here---end--->8---
At that point, if I pick another service process and kill it, shepherd
again fails to react to SIGCHLD (or doesn’t receive it):
--8<---cut here---start->8---
$ sudo herd status ntpd
Status of ntpd:
It is running since 08:44:31 AM (52 minutes ago).
Running value is 23814.
It is enabled.
Provides (ntpd).
Requires (user-processes networking).
Will be respawned.
$ sudo kill 23814
$ sudo herd status ntpd
Status of ntpd:
It is running since 08:44:31 AM (52 minutes ago).
Running value is 23814.
It is enabled.
Provides (ntpd).
Requires (user-processes networking).
Will be respawned.
ludo@ribbon ~/src/guix$ ps 23814
PID TTY STAT TIME COMMAND
23814 ?Zs 0:00 [ntpd]
--8<---cut here---end--->8---
If I repeat the same experiment while stracing shepherd, here’s what I
see:
--8<---cut here---start->8---
$ sudo herd status guix-publish
Status of guix-publish:
It is running since 08:44:32 AM (55 minutes ago).
Running value is 23822.
It is enabled.
Provides (guix-publish).
Requires (user-processes guix-daemon avahi-daemon).
Will be respawned.
$ sudo kill 23822
$ ps 23822
PID TTY STAT TIME COMMAND
23822 ?Zs 0:02 [guix publish]
--8<---cut here---end--->8---
… and the strace:
--8<---cut here---start->8---
1 rt_sigprocmask(SIG_BLOCK, NULL, [HUP INT TERM CHLD], 8) = 0
1 epoll_wait(13, [{events=EPOLLIN, data={u32=14, u64=14}}], 8, -1) = 1
1 accept4(14, {sa_family=AF_UNIX}, [112 => 2], SOCK_CLOEXEC|SOCK_NONBLOCK)
= 25
1 accept4(14, 0x7ffe6f8f0be0, [112], SOCK_CLOEXEC|SOCK_NONBLOCK) = -1
EAGAIN (Resource temporarily unavailable)
1 epoll_ctl(13, EPOLL_CTL_MOD, 14, {events=EPOLLIN|EPOLLRDHUP|EPOLLONESHOT,
data={u32=14, u64=14}}) = 0
1 epoll_wait(13, [], 8, 0) = 0
1 read(25, "(shepherd-command (version 0) (action status) (service
guix-publish) (arguments ()) (directory \"/home/ludo/src/guix\"))", 1024) = 118
1 epoll_wait(13, [], 8, 0) = 0
1 epoll_wait(13, [], 8, 0) = 0
1 epoll_wait(13, [], 8, 0) = 0
1 epoll_wait(13, [], 8, 0) = 0
1 epoll_wait(13, [], 8, 0) = 0
1 epoll_wait(13, [], 8, 0) = 0
1 epoll_wait(13, [], 8, 0) = 0
1 epoll_wait(13, [], 8, 0) = 0
1 epoll_wait(13, [], 8, 0) = 0
1 epoll_wait(13, [], 8, 0) = 0
1 epoll_wait(13, [], 8, 0) = 0
1 epoll_wait(13, [], 8, 0) = 0
1 epoll_wait(13, [], 8, 0) = 0
1 epoll_wait(13, [], 8, 0) = 0
1 epoll_wait(13, [], 8, 0) = 0
1 epoll_wait(13, [], 8, 0) = 0
1 write(25, "(reply (version 0) (result ((service (version 0) (provides
(guix-publish)) (requires (user-processes guix-daemon avahi-daemon)) (respawn?
#t) (docstring \"[No documentation.]\") (enabled? #t) (running 23822)
(conflicts ()) (last-respawns ()) (status-changes ((running . 1685083472)
bug#63726: time-machine without options does not get the latest commit
Hi,
On jeu., 25 mai 2023 at 23:03, Ludovic Courtès wrote:
> I had to check the code, but ‘guix time-machine’ follows the same logic
> as ‘guix pull’: it reads ~/.config/guix/channels.scm, and so on (that’s
> the ‘channel-list’ procedure).
--8<---cut here---start->8---
$ cat ~/.config/guix/channels.scm
(use-modules (guix ci))
(list (channel-with-substitutes-available
%default-guix-channel
"https://ci.guix.gnu.org;))
$ guix time-machine -C ~/.config/guix/channels.scm -- describe
Updating channel 'guix' from Git repository at
'https://git.savannah.gnu.org/git/guix.git'...
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
compute-guix-derivation 1013B
373KiB/s 00:00 ▕██▏ 100.0%
Computing Guix derivation for 'x86_64-linux'... \
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivations will be built:
/gnu/store/80sisjhmmb0sbvyylavm3c2rgjnhypw2-profile.drv
/gnu/store/3213n6v442d1zv17xidg8s48hx02f433-guix-daemon.drv
/gnu/store/77k19wqklyw4gvxqjjdg8ah4k9llb5c0-guix-command.drv
/gnu/store/3cyv2vdk3v0asjqbspzlgbzibk1f50p2-guix-system-tests-modules.drv
/gnu/store/9pq5bivbzg476svaqv38xjgwyhg0ml2k-guix-cli-core-modules.drv
/gnu/store/gpjmcxvr10fnzjvkwr7yf2wpyrzyb5nm-guix-packages-base-modules.drv
/gnu/store/gqamr3s5amc1ayqa4xbzv114zy6l8ac8-guix-system-modules.drv
/gnu/store/xv2yv334dpxvq8bw605avhcf6dv0smyp-guix-home-modules.drv
/gnu/store/yya1dwvx7svj588vnqznabqaa2ahv4a3-guix-cli-modules.drv
[...]
building profile with 1 package...
guix 849286b
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 849286ba66c96534bddc04df1a47d5692cbc977e
$ guix time-machine -- describe
guix 849286b
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 849286ba66c96534bddc04df1a47d5692cbc977e
$ mv ~/.config/guix/channels.scm /tmp/channels.scm
$ guix time-machine -C ~/.config/guix/channels.scm -- describe
guix time-machine: error: failed to load
'/home/simon/.config/guix/channels.scm': No such file or directory
$ guix time-machine -- describe
Updating channel 'guix' from Git repository at
'https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to 3299b40 (36 new commits)...
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
compute-guix-derivation 1016B
168KiB/s 00:00 ▕██▏ 100.0%
Computing Guix derivation for 'x86_64-linux'... -
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivations will be built:
/gnu/store/4gm2ay6gjsjq6iclmbm4jqnvja12axy2-profile.drv
/gnu/store/7b50p1xnh4r5ahfj4da8yb8xgzqdjsyv-guix-daemon.drv
/gnu/store/qgcnzghwqxkak53rhnggl73d6r1jkq4q-guix-command.drv
/gnu/store/1spf6ndyz62izy3xgr9v5jnjin305s2v-guix-cli-core-modules.drv
/gnu/store/3fib3w2cjl83r75zfllby6wp3znh362p-guix-system-tests-modules.drv
/gnu/store/7vn6pq6j5psjwlcgvl1nbgwlspamx1wx-guix-home-modules.drv
/gnu/store/9qr483y1law33nqdwz7bjr32sbkka2xw-guix-cli-modules.drv
/gnu/store/iq10xaghbj6435w4c6nmyqb3kwzs119f-guix-packages-base-modules.drv
/gnu/store/wzssfkmqywrqm86vjlyxzpf26d4h30qd-guix-system-modules.drv
[...]
building profile with 1 package...
guix 3299b40
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 3299b40b3599371890816b52d65a6a5ada1b1131
--8<---cut here---end--->8---
Hum. Now, I am not seeing anymore e499cb2. Related to #63667 [1]?
1: https://issues.guix.gnu.org/issue/63667
> Should we fix the doc or should we fix the code?…
What about this patch?
>From 63b862ed9f3d3b019af3c6926bc1737f573bdfe6 Mon Sep 17 00:00:00 2001
Message-Id: <63b862ed9f3d3b019af3c6926bc1737f573bdfe6.1685093404.git.zimon.touto...@gmail.com>
From: Simon Tournier
Date: Fri, 26 May 2023 11:26:32 +0200
Subject: [PATCH] doc: Reword guix time-machine without option.
* doc/guix.texi (Invoking guix time-machine): Reword the behaviour in the
absence of any option.
---
doc/guix.texi | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/doc/guix.texi b/doc/guix.texi
index 31dc33fb97..54f8a20196 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -4958,16 +4958,20 @@ Invoking guix time-machine
@xref{Channels} for more information.
@end table
-As for @command{guix pull}, the absence of any options means that the
-latest commit on the master branch will be used. The command
+Similarly as @command{guix pull}, the absence of any options means that
+either the user's @file{~/.config/guix/channels.scm} file, or either the
+system-wide @file{/etc/guix/channels.scm} file, or either the built-in
+default channels specified in the
bug#52362: guix import go error
Hi,
On jeu., 25 mai 2023 at 20:58, Nicolas Goaziou wrote:
> Oops! For the record, I meant:
>
>guix import go --recursive github.com/rclone/rclone
I get:
--8<---cut here---start->8---
$ ./pre-inst-env guix import go --recursive github.com/rclone/rclone
following redirection to `https://github.com/storj/eventkit?go-get=1'...
following redirection to `https://goftp.io/server/?go-get=1'...
following redirection to
`https://github.com/qingstor/qingstor-sdk-go?go-get=1'...
Backtrace:
In srfi/srfi-1.scm:
586:29 19 (map1 _)
586:29 18 (map1 _)
586:29 17 (map1 _)
586:29 16 (map1 _)
586:29 15 (map1 _)
586:29 14 (map1 _)
586:29 13 (map1 _)
586:29 12 (map1 _)
586:29 11 (map1 _)
586:17 10 (map1 (("github.com/yunify/qingstor-sdk-go/v3" #f)
("github.com/youmark/pkcs8" #f) ("github.com/winfsp/cgofuse" #f)
("github.com/t3rm1…" …) …))
In guix/import/utils.scm:
630:33 9 (lookup-node "github.com/yunify/qingstor-sdk-go/v3" #f)
In guix/memoization.scm:
98:0 8 (mproc "github.com/yunify/qingstor-sdk-go/v3" #:repo->guix-package
# #:guix-name #guix-package-…> …)
In unknown file:
7 (_ #
# (this is nothing))
In guix/import/go.scm:
708:10 6 (_ _ #:version _ #:repo _)
In ice-9/exceptions.scm:
406:15 5 (go-module->guix-package* . _)
In ice-9/boot-9.scm:
1752:10 4 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In guix/import/go.scm:
641:11 3 (go-module->guix-package "github.com/yunify/qingstor-sdk-go/v3"
#:goproxy _ #:version _ #:pin-versions? _)
In unknown file:
2 (substring "github.com/yunify/qingstor-sdk-go" 35 #)
In ice-9/boot-9.scm:
1685:16 1 (raise-exception _ #:continuable? _)
1683:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1683:16: In procedure raise-exception:
Value out of range 0 to< 33: 35
--8<---cut here---end--->8---
which is a bug but another one. :-)
Well, we can keep this bug open in order to address this other bug or
close it – since the issue with labels is done by Stephen’s patch – and
then open another one for tackle the issue above.
For instance, it reads,
--8<---cut here---start->8---
$ ./pre-inst-env guix import go github.com/yunify/qingstor-sdk-go
Backtrace:
In ice-9/boot-9.scm:
1752:10 14 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In unknown file:
13 (apply-smob/0 #)
In ice-9/boot-9.scm:
724:2 12 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8 11 (_ #(#(#)))
In guix/ui.scm:
2300:7 10 (run-guix . _)
2263:10 9 (run-guix-command _ . _)
In guix/scripts/import.scm:
89:11 8 (guix-import . _)
In ice-9/boot-9.scm:
1752:10 7 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In guix/scripts/import/go.scm:
116:29 6 (_)
In ice-9/exceptions.scm:
406:15 5 (go-module->guix-package* . _)
In ice-9/boot-9.scm:
1752:10 4 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In guix/import/go.scm:
598:11 3 (go-module->guix-package "github.com/yunify/qingstor-sdk-go"
#:goproxy _ #:version _ #:pin-versions? _)
In unknown file:
2 (regexp-exec # #f # #)
In ice-9/boot-9.scm:
1685:16 1 (raise-exception _ #:continuable? _)
1683:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1683:16: In procedure raise-exception:
In procedure regexp-exec: Wrong type argument in position 2 (expecting string):
#f
--8<---cut here---end--->8---
Cheers,
simon
bug#63726: time-machine without options does not get the latest commit
Hi, > Should we fix the doc or should we fix the code?… I vote for fixing the doc. Two reasons: 1. Having "guix time-machine" and "guix pull" behave in the same way is desirable. Less cognitive load for users. 2. What the doc says cannot be implemented in general. "The latest commit on the master branch" makes no sense for a setup with multiple channels, some of which may not even have a branch called "master". Cheers, Konrad.
bug#63728: GHC cannot find lrt
2023-05-25 22:25 bug-guix@gnu.org: Attempting to build a trivial Haskell program using ghc fails, as the linker cannot find the rt library: ``` ~ $ ghc -O2 test.hs Linking test ... /home/a/.guix-profile/bin/ld: cannot find -lrt: No such file or directory collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) ``` Glibc and gcc-toolchain are installed in the profile, and ~/.guix-profile/lib/librt.so.1 exists. Maybe this is related to this new bug, or the recent core-updates merge? https://issues.guix.gnu.org/63238 There is also this bug I had reported: https://issues.guix.gnu.org/63258 I suggest to merge this bug (63728) and the bug I just linked (63258). What do you think?
bug#63728: GHC cannot find lrt
2023-05-25 22:25 bug-guix@gnu.org: Attempting to build a trivial Haskell program using ghc fails, as the linker cannot find the rt library: Does installing gcc-toolchain:static help as a work-around?
