[LLVMdev] Practical --enable-shared LLVM builds.

Óscar Fuentes ofv at wanadoo.es
Wed Nov 12 13:58:35 PST 2008

It seems that --enable-shared builds are not used by LLVM developers
because the executables starts slowly. I guess this is related to the
number of symbols the dynamic linker has to resolve. If we could reduce
the symbols exported to those which are required, maybe the startup time
would become bearable.

One way of doing this is to add annotations to each public class and
function (such as __declspec(dllexport)). The hard work here is to
determine which classes are public, mostly because inter-library
dependencies. Then we have the issue of cyclic dependencies. Today
cyclic dependencies are solved with the creation of partially linked
objects, but this defeats the advantages of having shared libraries.

OTOH, I'll like to distribute LLVM as a separate set of files and not to
force my users to update them every time my compiler changes.

One solution is to add annotations only to those classes that shall be
visible by the LLVM user and create one big dll comprising all required
components. This big dll would be smaller and load faster than the sum
of individual LLVM libraries. The counterpart, from the POV of the LLVM
developer, is that you get static constructors that you don't want to

Some questions arise:

   What's the estimated ratio of public/private symbols for a LLVM
   library, taking into account inter-library dependencies.

   Same question but without inter-library dependencies. Just those
   needed by executables.

   As a LLVM developer, do you see any advantage on using shared
   libraries? (supposing that we overcome the startup slowdown).

   Thinking as a LLVM user, are shared libraries interesting to you? If
   the answer is yes, is the one-big-dll mentioned above useful to you?


More information about the llvm-dev mailing list