Cross compilation question


I wonder if it's possible to cross compile regular linux packages
(autotools based) into llvm bitcode.
Such bitcode could run on multiple target platforms using lli.
So for example if we take 'tar' sources and compile them, we have
'tar' bitcode.
We can run it using 'lli tar'.

If it was possible in general, then probably building lots of linux
packages could be easy
using for example openembedded distribution.

BTW. This question is more theoretical than actually needed for
something particular.

So I tried to do something like this or 'tar' sources:
./configure --host none-llvm --target none-llvm

I had to rename llvm-gcc etc into none-llvm-*, because autotools complained on
non recognized architecture when I used 'llvm'.

But I got an error later:
  GEN rmt-command.h
make all-am
make[3]: Entering directory `/home/joker/tar-1.23/lib'
  CC rtapelib.o
  AR libtar.a
make[3]: Leaving directory `/home/joker/tar-1.23/lib'
make[2]: Leaving directory `/home/joker/tar-1.23/lib'
Making all in rmt
make[2]: Entering directory `/home/joker/tar-1.23/rmt'
  CCLD rmt
../gnu/libgnu.a: could not read symbols: Malformed archive
collect2: ld returned 1 exit status
make[2]: *** [rmt] Error 1
make[2]: Leaving directory `/home/joker/tar-1.23/rmt'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/joker/tar-1.23'
make: *** [all] Error 2

The other problem is that probably linker (llvm-ld) generates
platform specific executable instead of bitcode in this case.

So if you had any clues how I could fix this, then
it would be great.

BTW. I'm not sure also if that would work for technical reasons, like
binary compatibility.

Hi Rafal,

LLVM's bitcode is not target independent in the manner you're hoping for. You can't take bitcode generated for x86 and use it on ARM, for example, or bitcode generated for Linux and use it on Darwin.


The problem is generally not the bitcode itself, but that a lot of
target details leak into it from target specific headers. This starts by
simple issues like the pointer size and goes as far as different calling
conventions and resulting storage needs for stdarg.h.