SELF: Anatomy of an (alleged) failure

Someone already has. It's called qemu.

>What would be interesting would be a bytecode architecture [...]

We have something definitely better: source code.

Allowing for the distribution of a (more or less) universally-runnable, auto-sustained and self-contained component will ultimately result in making easier the distribution of closed source program, which is something we should contrast.

If you go look at some of the older LLVM papers they pretty much describe doing this... (I don't know if anyone implemented it, but given that they DO have a JIT compiler for LLVM IR already I think you could probably already do this in a limited form see http://llvm.org/cmds/lli.html the current llvm command that will run a LLVM IR bytecode object file with the LLVM JIT)

The papers talk about profiling and optimizing the IR and writing that back to the binary, so you get a binary optimized for your workload.

This still has the issues of library incompatibilities across architectures (even within the same distro) since the library may not have all the same options compiled in, or many export a slightly different set of symbols or all kinds of other things...

This has been tried many times, including (but not limited to) TDF (http://en.wikipedia.org/wiki/TenDRA_Distribution_Format) and ANDF (http://en.wikipedia.org/wiki/Architecture_Neutral_Distrib...).

I believe ANDF was the basis for some failed UNIX standard in the early 90s, but that's long before my time.

There's at least one more recent attempt along the same lines (forgotten its name).

> What would be interesting would be a bytecode architecture, like some sort of LLVM IR, compiled via a JIT at run time.
> This way the same "executable" would run on ARM, x86-32, x86-64...

You man, like... Java?

This is why the kernel-mailing is hostile.

Can you even get one CD to boot on both ix86 and ARM or PowerPC? Even if you can, along with getting the right kernel to boot up, you should be to symlink in the correct binary directories for the architecture.

I'm having a lot of trouble finding any case where FatELF can't be replaced by shell scripts and symlinks. You want to support both ix86 and AMD-64 with your game; have the executable name run a shell script that runs the right binaries.

Yes, binary compatibility is easier than most people seem to think, but it is also very frequently done wrong (including by Mr. Gordon, I generally have make stuff he's packaged stop using at least 2 or 3 bundled libraries before it works (if I'm not using the Gentoo ebuild of it...), he tends to bundle libstdc++ and libgcc, as well as SDL... all of these have had a stable ABI for a while now, and if the ABI changes, so does the soname so distros can ship a compat package (which they generally do) so there's no need to distribute them, the only people who benefit would be people with old versions that are missing new API that the game uses, it's irritating. I bought the Humble Bundle and all the games that weren't flash based didn't start due to the bundled libraries causing breakage)

These days you mostly have to worry about make sure you compile on a system that has old enough versions of everything that you're not using newer versions of stuff than your users will have (eg use g++ 4.3 so that Gentoo users that use the stable compiler don't have to install newer gcc and mess about with LD_LIBRARY_PATH so your app can find the newer libstdc++, it's nice since g++ 4.4 and 4.5's libstdc++ is backwards ABI compatible with all the older ones (4.0 and later, 3.x is a separate issue, but you can both available at once so you just need a compat package)) You don't even need to statically link many things, unless you have reason to believe they will not be packaged by your user's distro.