Ludovic Courtès writes:
Hi!
> Ludovic Courtès <l...@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:
>
> 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
>
> (The ‘file’ command does manage to recognize GNU/Hurd binaries, but I
> don’t know how it does it.)
Looking at the file sources, it uses do_os_note, look:
--8<---------------cut here---------------start------------->8---
$ 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
--8<---------------cut here---------------end--------------->8---
> 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 ;-)
Greetigs,
Janneke
--
Jan Nieuwenhuizen <jann...@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
