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:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,use(guix elf)
scheme@(guile-user)> ,use(rnrs io ports)
scheme@(guile-user)> (define e (parse-elf (call-with-input-file "/gnu/store/vq7zyb4hmlrafflmrcjbqccxp4dsx0s3-bash" get-bytevector-all)))
scheme@(guile-user)> (elf-abi e)
$6 = 0
scheme@(guile-user)> ELFOSABI_GNU
$7 = 3
scheme@(guile-user)> (define e2 (parse-elf (call-with-input-file "/bin/sh" get-bytevector-all)))
scheme@(guile-user)> (elf-abi e2)
$8 = 0
--8<---------------cut here---------------end--------------->8---

(The ‘file’ command does manage to recognize GNU/Hurd binaries, but I
don’t know how it does 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?

Ludo’.