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

Domagoj Babic babic.domagoj at gmail.com
Mon Dec 11 20:06:51 PST 2006


Hi,

On 12/11/06, Scott Michel <scottm at rushg.aero.org> wrote:
> 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?

For my application, byte-code emission was the crucial reason why I
decided to go with LLVM rather than other front-ends. In general, I
think I made a good decision, but when I need to spend 2 days to compile
a simple app to bytecode files or a week to fix code after
ISA/types/streams/interface change, it gets me thinking....

> 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 hacked a replacement for llvm-collect2 (explained below), but such
hackery is really not a way to go in the long term. I'm very hopeful
that Chandler's work will solve the problem for good.


Hack explained:
1) rename
llvm/libexec/gcc/x86_64-unknown-linux-gnu/4.0.1/collect2
to
collect2-llvm
2) put the attached script collect2 in the same directory
3) export CC=llvm-gcc CXX=llvm-g++

The script will call gccld if -enable-gccld is passed. So you can
configure without the switch, and make with something like:

make CFLAGS+=-emit-llvm CXXFLAGS+=-emit-llvm LDFLAGS+=-enable-gccld
[If your Makefile doesn't handle LDFLAGS properly, use -Wl,-enable-gccld.]

Possible outcome:
$ ./a.out
bash: ./a.out: No such file or directory
$ file a.out
a.out: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for
GNU/Linux 2.6.0, dynamically linked (uses shared libs), for GNU/Linux
2.6.0, not stripped
$ ls -l a.out
-rwxr-xr-x 1 <login> <login> 180422 2006-12-10 16:25 a.out

If you do
$ strings a.out | grep \.so

on the code compiled with llvm-collect2 and llvm-collect2 called by the
script, you might notice a difference in the libraries it gets linked
with, so in my case it links with a library that doesn't exist on the
system, probably the script doesn't handle paths/LD_LIBRARY_PATH
correctly. At that point I didn't have the patience to try to figure
exactly what's going on, so I just added a symbolic link:
$ ln -s /lib64/ld-linux-x86-64.so.2 /lib/ld64.so.1

[ collect2 patches welcome ;-) ]

I successfully compiled 20 or so apps, some fairly large ones (like wine)
with the script.


Finally, I need to mention that all the credit for the idea to write
such script goes to Reid. All the bugs are exclusively mine :-)

Domagoj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: collect2.bz2
Type: application/x-bzip2
Size: 1108 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20061211/9ca27744/attachment.bin>


More information about the llvm-dev mailing list