GNU bug report logs - #43668
Daemon tries to build GNU/Hurd derivations on GNU/Linux

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Ludovic Courtès <ludo <at> gnu.org>
Subject: bug#43668: closed (Re: bug#43668: Daemon tries to build GNU/Hurd
 derivations on GNU/Linux)
Date: Thu, 01 Oct 2020 10:52:02 +0000

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

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 43668 <at> debbugs.gnu.org.

-- 
43668: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=43668
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Ludovic Courtès <ludo <at> gnu.org>
To: Jan Nieuwenhuizen <janneke <at> gnu.org>
Cc: 43668-done <at> debbugs.gnu.org
Subject: Re: bug#43668: Daemon tries to build GNU/Hurd derivations on GNU/Linux
Date: Thu, 01 Oct 2020 12:51:19 +0200

Hi,

Jan Nieuwenhuizen <janneke <at> gnu.org> 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’.

[Message part 3 (message/rfc822, inline)]

From: Ludovic Courtès <ludo <at> gnu.org>
To: <bug-guix <at> gnu.org>
Subject: Daemon tries to build GNU/Hurd derivations on GNU/Linux
Date: Mon, 28 Sep 2020 10:43:06 +0200

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’.

Previous Next

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