On 19/11/12 23:17, Ingo Weinhold wrote: [...] > PS: What I'd really like to see is support for LLVM bytecode binaries. > Why fat when it can be portable? It's been done, and quite successfully: http://en.wikipedia.org/wiki/Architecture_Neutral_Distribution_Format http://en.wikipedia.org/wiki/TenDRA_Compiler TenDRA and ANDF died the death, but the source is still around. Ideally, doing LLVM bytecode binaries should be fairly easy, as the toolchain is already there; doing the final-stage translation at install time is a single invocation of llc. Practically, unfortunately, it doesn't work in real life these days as with the advent of 64-bit processors C and C++ now bake architecture-specific information into the code as part of the compilation process. e.g.: int i = sizeof(void*); int j = i * 2; int k = (void*)(char*)j; LLVM bitcode does have the ability to encode this sort of stuff into the format, but the semantics don't match C. clang doesn't even bother to try and will produce different bitcode for the above depending on what architecture you tell it you're compiling. And then of course as soon as you start talking about C++ and object layouts in memory you're in a hideous world of pain, and can kiss any kind of ABI conformance goodbye. (If you want to see how to do this *wrong*, go look at 'natural indexing' in the EFI bytecode spec...) That said, you can make it work provided you're willing to limit yourself to a lowest-common-denominator memory layout. For my day job I do this kind of thing for a living (see http://antixlabs.com); we use ILP32 everywhere, because we're targeting games and don't need 64-bit addresses. Is Haiku willing to do that? -- ââââ ïïïïïïïïïïïïïï âââââ http://www.cowlark.com âââââ â "Of course, on a sufficiently small planet, 40 km/hr is, in fact, â sufficient to punt the elastic spherical cow into low orbit." --- â Brooks Moses on r.a.sf.c