[LLVMdev] ld with gold-plugin can do this?

Nick Lewycky nicholas at mxc.ca
Wed Sep 23 00:00:51 PDT 2009

Sanjiv Gupta wrote:
> Nick Lewycky wrote:
>> Sanjiv.Gupta at microchip.com wrote:
>>> A common followup question is "but how do I link native libraries into
>>> my .bc file". You don't. A .bc file is llvm ir, you can't put a native
>>> binary library into a .bc (barring sticking it in as a string, etc).
>>> The build then looks like:
>>> a) 'llvm-gcc -c -flo -O2' to generate the .bc files.
>>> b) 'llvm-ld' to combine them into a single .bc. No, not a .so nor a .a.
>>> c) 'llc' to turn your combined .bc into a .s
>>> d) 'as' to turn your .s into a .o
>>> e) 'ld' to turn your .o into a .so or final executable. This is the step
>>> where you get to specify all the native libraries to link with.
>>> You can use 'gcc' to merge steps d and e (it just runs as and ld for
>>> you). Or you can use the gold plugin to merge steps b through e, but
>>> with the added benefit that it will optimize slightly better. See the
>>> llvm LTO documentation on why.
>>> [Sanjiv] - This is what PIC16 does. llvm-ld has an option called '-b' 
>>> that you can
>>> use to specify the output bitcode file name. Unfortunately, llvm-ld 
>>> always tries to
>>> generate a native executable (or a shell script) as well and 
>>> currently there is no way to disable that.
>>> Maybe an option like '-no-native' will be come handy.
>> Yes there is, it's -link-as-library.
>> Nick
> Well, -link-as-library is not quite same as a building a final 
> executable .bc.

.bc files aren't executable so I'm not entirely sure what you mean. 
'llvm-ld -link-as-library' takes a group of .bc files and merges them 
before running the link-time optimizations over them, then emits the 
result as a .bc file.

> The set of optimizations run is also different.

How so?

Checking llvm-ld's source, the only possible difference I can see is 
that passing -link-as-library will cause llvm-ld to ignore the 
-post-link-opts flag which almost certainly doesn't matter because you 
were almost certainly not using it.


More information about the llvm-dev mailing list