llvm dev - May 2016 - Creating and using "shared library" of LLVM IR

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160513/11796cc0/attachment.html>

> 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).


-- 
Mehdi


> 
> 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>

>
> 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).
>
I just want to avoid modifying the application's build system. If
there's
no other way, I could go in and change the build scripts, but I'd like to
avoid doing that as much as possible.

Tarun
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160513/794bbebb/attachment.html>