> The ELF ABI specifies how functions are called.  It is expected that a
> binary will be dynamically linked against libc.so.  So, in principle,
> details of system call handling can all be hidden in libc.so.  In
> practice, there seem to be some problems.
>
> The easy solution is to use a different interpreter program.  I
> believe that is how Linux distinguishes SVR4 binaries, for example.

Well, all of the operating systems that I know of on the i386 which use ELF
all seem to use /lib/libc.so as the interpreter.  SCO does, UnixWare does,
"stock" SVR4 (at least, the NCR 3000 binaries that Oracle ships) does, Solaris
does, Linux does.

None of these operating systems can reliably run *all* of the other variants'
binaries.  Naive UnixWare binaries often don't even work on Solaris, because
they expect SVR4.2 libc behaviour.

How is the libc.so for system X supposed to tell that it's interpreting a
binary for system Y, and should behave accordingly, if there's no canonical
way for it to figure out?

This is a horrible, nasty botch.  Even if one were to change ELF today to
add meaning to one of the bytes in the ident field that nobody uses, there
are thousands of binaries out there which are *not* all built for stock SVR4
which will continue, unless relinked or edited in place, to have the wrong
value.  Not to mention that most operating systems don't bother to look past
E L F in that header just now, so problems with widely-installed legacy
systems will persist.

So we're essentially where we started.  NetBSD can go modify ELF in some
nonstandard way, producing something that's different and better, but isn't
quite "standard" ELF and will require toolchain modifications to work.
Historically, there have been issues involved in actually getting these
changes merged back into the trunk versions of the tools we use.  Perhaps
that's better now, and will stay better in the future, but it hasn't always
been, certainly.

NetBSD's not the only project with this problem.  I know people at or working
with SCO who are tearing their hair out trying to get support for ELF on their
systems included in certain FSF-maintained programs, notably GCC and Emacs.

Thor