There is no standard way. There is no provision in ELF to handle
multiple architectures in the same file.
It wouldn't be too hard to modify binfmt_elf to allow for direct
calls from another loader that specifies an offset into a given file.
All that you'd need then is to whip up some header to go on the
front of the concatenation of the different binaries.
> > Would there be any use for data and code sharing?
> Of course! Endian information is provided in the elf-headers, too (and
> will be auto swapped by the loader/binfmt_elf??)
Hah. Sharing data is _very_ hard.
You'd have to modify the compiler to get it to output things that
you can expect to be able to share in separate sections (easy).
This is basicly limited to strings, unless you want to muck with
partially shared sections (sparc shares with ppc, but i386 and
alpha don't share with anyone due to endian and word size).
Then you'd have write a new linker that could take the object files
from all of the different architectures and link them into the fat
binary in one go. This is because you need to see all of the relocs
in order to get things fixed up for the non-shared sections.
The issue of how to position the shared segment in memory among all
the different architectures I leave as an excercise to the reader.
In your pondering, recall the different shapes of the VM available
to the user on different architectures.
Fat binaries are, IMO, a waste of effort. Just bleeding deal with
N binaries for N architectures. It just isn't that hard.
r~