[LLVMdev] [RFC]Extending lib/Linker to support bitcode "shared objects"
Rafael Ávila de Espíndola
rafael.espindola at gmail.com
Tue Dec 13 21:27:11 PST 2011
> $ llc bar.bc -filetype=obj -o bar.o
> $ clang -shared -o bar.so bar.o
> $ clang -use-gold-plugin foo.o bar.so -o t
>
> Is that correct? In particular, "lld t" should show a dependency on bar.
> Any particular reason for not adding this to the plugin api?
>
> The result is a native .so here. My goal is to have a bitcode result.
>
> gold plugin with mods supports that as well, but it would be nice to
> avoid dependency on gold and gold plugin to simplify things.
Sorry, I meant equivalent only in the produced executable (t). In the
above example the bar.bc is your "shared IL library" which I assume
already exists. You want to produce a executable (t) which has a
dependency on a shared library with the symbols defined in foo.bc.
Is that the use case?
> I believe that Emscripten does not use gold and gold plugin at the
> moment. They use
> llvm-link: https://github.com/kripken/emscripten/wiki/Building-Projects
I think that is the current implementation, yes.
> I fully agree that all the features I want from the bitcode linker may
> be achieved with gold + gold plugin (with mods to both parts), but I
> would like to stay away from this dependency. Partly, because
> maintaining modified gold and gold plugin is no fun, partly because gold
> + gold plugin is hardly broken under cygwin.
I understand. I was just pointing that emacscriten case looks different
from what you have. I don't see where an LLVM IL library (libc in your
example) would fit. All that is needed is a stub with the functions that
will be defined in JS in the end.
Cheers,
Rafael
More information about the llvm-dev
mailing list