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

[Ludovic Courtès]

Hi!<

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

>> Ludovic Courtès <ludo@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’.