Hello Manolis and all!
Manolis Ragkousis <manolis...@gmail.com> skribis:
> Rene is using a personal branch based with modification based on the
> guix-hurd work.
>
> Rene are you still using the binaries I had provided?
>
> Theoretically we could do that. But unfortunately 1) the Guix to Hurd
> cross-compilation support breaks faster that I can keep up trying to fix
> 2) even when we get the binaries we will definitely have issues with the
> initial tool-chain.
>
> Can the current master build `guix build --target=i586-pc-gnu
> bootstrap-tarballs` ?
Of course it does! :-)
I was about to commit the {mkdir,tar,xz,bash} in
gnu/packages/bootstrap/i586-gnu, and then thought maybe the guile
bootstrap tarball as well could be added to bootstrap, but that turned
out to be more complicated.
First, /proc/self lookups were not working for us because our libc was
lacking the implementation of “pid/…” magical lookups; fixed in
92391eaf8df8fecbf6844c57ce5bcd3014eb5d28.
Second, our static Guile 2.2 (from ‘bootstrap-tarballs’) is still on
GNU/Hurd (I tried it on the ‘darnassus’ machine). What I see is this:
--8<---------------cut here---------------start------------->8---
ludo@darnassus:~$ G/bin/guile --version
guile: warning: failed to install locale
ludo@darnassus:~$ echo $?
0
ludo@darnassus:~$ rpctrace G/bin/guile --version
[…]
112<--150(pid14979)->dir_lookup
("home/ludo/G/lib/guile/2.2/ccache/ice-9/command-line.go" 4194305 0) = 0 1
"ludo/G/lib/guile/2.2/ccache/ice-9/command-line.go" 177<--185(pid14979)
task139(pid14979)->mach_port_mod_refs (pn{ 24} 0 1) = 0
177<--185(pid14979)->dir_lookup
("ludo/G/lib/guile/2.2/ccache/ice-9/command-line.go" 4194305 0) = 0 1 ""
174<--187(pid14979)
task139(pid14979)->mach_port_deallocate (pn{ 24}) = 0
task139(pid14979)->mach_port_deallocate (pn{ 24}) = 0
174<--187(pid14979)->term_getctty () = 0xfffffed1 ((ipc/mig) bad request
message ID)
174<--187(pid14979)->io_seek (0 2) = 0 77749
174<--187(pid14979)->io_map () = 0 177<--178(pid14979) (null)
task139(pid14979)->vm_map (0 77749 0 1 177<--178(pid14979) 0 1 1 7 1) = 0
19619840
task139(pid14979)->mach_port_deallocate (pn{ 24}) = 0
task139(pid14979)->mach_port_deallocate (pn{ 26}) = 0
task139(pid14979)->vm_protect (19685376 4808 0 3) = 0
148<--152(pid14979)->proc_mark_exit_request (0 0) = 0
task139(pid14979)->task_terminate () = 0
Child 14979 exited with 0
--8<---------------cut here---------------end--------------->8---
IOW, it exits right after its ‘mprotect’ call.
For comparison, this is what it looks like on GNU/Linux:
--8<---------------cut here---------------start------------->8---
stat("/gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4/lib/guile/2.2/ccache/ice-9/command-line.go",
{st_mode=S_IFREG|0444, st_size=81741, ...}) = 0
openat(AT_FDCWD,
"/gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4/lib/guile/2.2/ccache/ice-9/command-line.go",
O_RDONLY|O_CLOEXEC) = 7
lseek(7, 0, SEEK_END) = 81741
mmap(NULL, 81741, PROT_READ, MAP_PRIVATE, 7, 0) = 0x7fd08126d000
close(7) = 0
mprotect(0x7fd08127d000, 8128, PROT_READ|PROT_WRITE) = 0
openat(AT_FDCWD,
"/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/share/locale/en_US.utf8/LC_MESSAGES/messages.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD,
"/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/share/locale/en_US/LC_MESSAGES/messages.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD,
"/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/share/locale/en.utf8/LC_MESSAGES/messages.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD,
"/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/share/locale/en/LC_MESSAGES/messages.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
write(1, "guile", 5guile) = 5
write(1, " (", 2 () = 2
write(1, "GNU Guile", 9GNU Guile) = 9
write(1, ") ", 2) ) = 2
write(1, "2.2.4", 52.2.4) = 5
[…]
--8<---------------cut here---------------end--------------->8---
We can recognize th stat/seek/mmap/mprotect sequence, but then the
GNU/Linux version keeps going instead of exiting.
Rene, Manolis: any ideas? :-)
Thanks,
Ludo’.
