Why LLVM libraries are static?

Hello!

Is there any reason why after "./configure; make" all LLVM libraries are .a
files, and not .so files?

The problem with .a files is that if I make a plugin, say code generator, it
should link in pretty large LLVM libraries. If libraries were shared, this
would not be required.

Alternatively, tools that load plugins can probably mark all symbols as
dynamically exported, by using gcc option

  -Wl,--export-dynamic

Again, this will allow plugins to use LLVM symbols without linking in a
static copy of them.

Or I just did not notice some option to configure?

Thanks,
Volodya

Vladimir Prus wrote:

Alternatively, tools that load plugins can probably mark all symbols as
dynamically exported, by using gcc option

  -Wl,--export-dynamic

Scratch this part, this option is in fact used when linking llc. The
question why libs are static still stands, though.

- Volodya

Is there any reason why after "./configure; make" all LLVM libraries are .a
files, and not .so files?

Initially we had all of the LLVM libraries be .so files. The problem with this is that it was *really* slow to start up an LLVM program (e.g. llc or opt) that is set up like this.

However, if you want to, you should be able to build the libraries as shared objects, by adding these options in the makefile for the library:

SHARED_LIBRARY = 1
LOADABLE_MODULE = 1

The problem with .a files is that if I make a plugin, say code generator, it
should link in pretty large LLVM libraries. If libraries were shared, this
would not be required.

True. For a tool where you aren't starting up and shutting down a lot (e.g. an IDE with an integrated compiler, or a long-living tool that uses a JIT), using shared objects makes sense.

Or I just did not notice some option to configure?

It isn't THAT easy, but you should be able to do it by changing the makefiles as above.

-Chris