[llvm-dev] Creating and using "shared library" of LLVM IR

Mehdi Amini via llvm-dev llvm-dev at lists.llvm.org
Fri May 13 10:40:04 PDT 2016

> On May 13, 2016, at 10:27 AM, Tarun Prabhu via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> I am trying to use LLVM to get the IR for a whole program. The program's Makefile is somewhat complicated so I have written wrappers which emit LLVM IR at every step in the process instead of ELF object files and executables. My problem is that during linking, I get "multiple definition" errors. Here is a small example:
> file: a.c 
> ---------
> int f_a(int m) { return m + 1; }
> file: b.c
> ----------
> int f_a(int);
> int f_b(int n) { return f_a(n); }
> file: driver.c 
> --------------
> int f_b(int);
> int main(int argc, char *argv[]) {
>   return f_b(argc);
> }
> $ clang -flto -Wl,-plugin-opt=emit-llvm -shared -o libA.so a.c
> $ clang -flto -Wl,-plugin-opt=emit-llvm -shared -o libB.so b.c -L. -lA
> $ clang -flto -Wl,-plugin-opt=emit-llvm -o driver driver.c -L. -lA -lB
> All the .so files here are obviously now bitcode files. The last command fails with a "multiple definition" error because both libB.so and libA.so contain a definition for f_a. 

I've never used .so that are bitcode files before, that seems weird to me, since the point of a .so is to stay a separated entity and not being linked into the main executable.
Any reason you're not using static archives? It seems to correspond more to what you're trying to do (i.e. LTO all the code in a single binary).


> My question is: Is there a way to have the linker only import the definitions from shared objects when linking the final executable and in all other cases just use the declaration? Or, is there a way to get the linker to pick one of several identical definitions? 
> Thanks,
> Tarun
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160513/13fc19de/attachment-0001.html>

More information about the llvm-dev mailing list