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: Ludovic Courtès <ludo <at> gnu.org>
To: Jan Nieuwenhuizen <janneke <at> gnu.org>
Cc: 43668 <at> debbugs.gnu.org
Subject: bug#43668: Daemon tries to build GNU/Hurd derivations on GNU/Linux
Date: Mon, 28 Sep 2020 22:45:17 +0200

Hi!<

Jan Nieuwenhuizen <janneke <at> gnu.org> skribis:

>> Ludovic Courtès <ludo <at> gnu.org> skribis:
>>
>>> 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.
>>
>> The thing is that x86 GNU/Hurd and GNU/Linux ELF binaries are
>> indistinguishable AFAICS since they both use ELFOSABI_NONE:

[...]

> Looking at the file sources, it uses do_os_note, look:
>
> $ readelf -a $(guix build --target=i586-pc-gnu hello)bin/hello
>
> Displaying notes found in: .note.ABI-tag
>   Owner                Data size 	Description
>   GNU                  0x00000010	NT_GNU_ABI_TAG (ABI version tag)
>     OS: Hurd, ABI: 0.0.0

Oh, well done, I browsed ‘file’ but didn’t find it.

>> So I think we can’t count on an ‘execve’ error and thus have to treat
>> this case (same architecture but different OS kernel) specially, as
>> shown below.
>>
>> Thoughts?
>
> If that really doesn't work...then yeah (yuck ;-)

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

(Besides, it would be interesting to understand how the libc/Hurd
startup code ends up segfaulting on GNU/Linux.)

Ludo’.

Previous Next

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