Subject: bug#43668: closed (Re: bug#43668: Daemon tries to build GNU/Hurd derivations on GNU/Linux)

From: [email-masked] (GNU bug Tracking System)
Date: Thu, 01 Oct 2020 10:52:02 +0000

Your bug report

#43668: Daemon tries to build GNU/Hurd derivations on GNU/Linux

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

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
43668: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=43668
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#43668: Daemon tries to build GNU/Hurd derivations on GNU/Linux
From: Ludovic Courtès <[email-masked]>
To: Jan Nieuwenhuizen <[email-masked]>
Cc: [email-masked]
Date: Thu, 01 Oct 2020 12:51:19 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

Hi,

Jan Nieuwenhuizen <[email-masked]> skribis:

>> Yeah, I think we’ll have to do this hack (we’re not going to parse ELF
>> files and all to determine whether to call ‘execve’.)
>
> Ah, we're C++; I was thinking Guile and "we surely have" an ELF library.
> That's allright then.  Let's have this workaround.

Yeah.  Even with a library, it doesn’t sound right to parse files
beforehand.  I think it’s up to the kernel to make the relevant check,
but perhaps there are good reasons why this isn’t happening here.

Anyway, pushed as 9556ac498fd648147ad7d3b52ec86202d0a8e171!

>> (Besides, it would be interesting to understand how the libc/Hurd
>> startup code ends up segfaulting on GNU/Linux.)
>
> Hmm...are you saying something like "it could run until it wants to RCP
> Mach or Hurd?"  Might it "just load" shared libraries...

Yeah I would expect it to run code up to the first Mach syscall but here
it segfaults so maybe it crashes earlier.

Ludo’.

Subject: Daemon tries to build GNU/Hurd derivations on GNU/Linux
From: Ludovic Courtès <[email-masked]>
To: <[email-masked]>
Date: Mon, 28 Sep 2020 10:43:06 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

Here’s the problem:

--8<---------------cut here---------------start------------->8---
$ guix build guile-bootstrap -s i586-gnu
La jena derivo estos konstruata:
   /gnu/store/xi7r3bryibnyvjrs6avv8qp676mja4w2-guile-bootstrap-2.0.drv
building /gnu/store/xi7r3bryibnyvjrs6avv8qp676mja4w2-guile-bootstrap-2.0.drv...
builder for `/gnu/store/xi7r3bryibnyvjrs6avv8qp676mja4w2-guile-bootstrap-2.0.drv' failed due to signal 11 (Segmentation fault)
build of /gnu/store/xi7r3bryibnyvjrs6avv8qp676mja4w2-guile-bootstrap-2.0.drv failed
View build log at '/var/log/guix/drvs/xi/7r3bryibnyvjrs6avv8qp676mja4w2-guile-bootstrap-2.0.drv.bz2'.
guix build: error: build of `/gnu/store/xi7r3bryibnyvjrs6avv8qp676mja4w2-guile-bootstrap-2.0.drv' failed
$ uname -o
GNU/Linux
$ guix describe 
Generacio 160   Sep 25 2020 23:40:20    (nuna)
  guix a0d4aa2
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: a0d4aa2457d7e36012143ffe3fbc9dd4bc20ca4f
--8<---------------cut here---------------end--------------->8---

It’s no wonder that the GNU/Hurd executable fails to run on GNU/Linux.
The reason the daemon tries to run it anyway is because of the hack
introduced in 7bf2a70a4ffd976d50638d3b9f2ec409763157df, in support of
transparent emulation via binfmt_misc.

Ludo’.