[LLVMdev] How to compile apps to bc files with the new llvm-gcc4?

[Scott Michel]

Reid Spencer wrote:
> Chandler/Domagoj,
> 
> On Sun, 2006-12-10 at 10:53 -0500, Chandler Carruth wrote:
> 
>>Unless I'm missing something, the problem lies directly with the fact
>>that you are trying to do a link-stage operation with the GCC
>>frontend. GCC, by default, probably runs "ld" or another system
>>linker, which grabs the executable from binutils. This linker hasn't
>>been modified (yet) to include support for .bc files, but you're
>>compiler is emitting byte code to the *.o files. That is why the
>>linker barfs, and tries to interpret as a script. 
> 
> 
> Correct. In a discussion with Domagoj on IRC, it turns out that he
> actually doesn't want to link a native executable. He just wants to get
> a single linked .bc file for each program. llvm-gcc3 used to do this
> because it linked with gccld which produces a .bc file and a shell
> script for running that bc file with lli. I suggested to him that he
> change his makefiles to simply link the llvm-gcc4 produced bytecode
> files with gccld as did llvm-gcc3.

Here's where my issue about DTRT with llvm-gcc (or whatever your prefix
to llvm tools happens to be) resurfaces. I'm keenly aware that Chris
thinks that one really ought to be careful with having llvm-gcc emit
bytecode. But frankly, if that's the case, what's the point of emitting
byte code in the first place?

It might be a good interim step to hack the frontend so that llvm-ld
gets invoked (and I'm aware of problems like passing '-gcse' to the ld
phase when the frontend collects the arguments.) Even if emitting
bytecode only happens with "-O4", you still run into the same problem at
link time. Unless you override LD in your makefile or some other hack,
which, BTW, doesn't necessarily work either.

>>I am actually planning on working on integration between binutils' ld
>>and LLVM to allow just this functionality. I'll be working on this
>>over the holidays, and hopefully will get something working by mid
>>January. Until then, directly using the LLVM linking facilities to
>>handle the bytecode is probably the best if not only option. 
> 
> 
> We look forward to LTO in binutils. This will be a great addition to
> LLVM (and binutils) that will make using bytecode more transparent than
> ever.

While that would be cool, it still remains that they potentially aren't
going to be installed in the right place for gcc to pick them up, or
worse, you get mismatches between the distro's concept of binutils vs.
llvm-gcc's concept of binutils. That becomes the headache that I suspect
we're all trying to avoid.