[LLVMdev] Practical --enable-shared LLVM builds.
scott.llvm at h4ck3r.net
Wed Nov 12 17:24:24 PST 2008
I'm not sure that it meets your needs, but in making C# bindings, I
had to build the one-big-dll with only public stuff exported. I did
this by processing the llvm-c headers into a linker script (so the
llvm-c interface is the determiner of what's visible, rather than
requiring decoration in the source code).
The llvm-c interface mostly only covers front end IR building, not
code-gen or opt passes, but it might give you an idea of the ratio of
So, in the "LLVM user" category, yes, I'm interested in the
one-big-dll, though I'd probably only use the C-interface, not the C++
parts. I'm not sure how practical it is to use exporting C++ features
across DLL boundaries and trying to upgrade LLVM and your compiler
separately, as small changes would affect name mangling. You'd be
requiring quite a large scale "freeze" on a lot of LLVM changes for
that to work, I think.
I'd also be interested in working on getting at the equivalent
functionality of `llc' and `opt' via the llvm-c interface too, if you
think that might be the way to go.
 To be contributed once I'm finally upgraded to somewhere near
HEAD, if anyone's interested in them
On Wed, Nov 12, 2008 at 1:58 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:
> 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?
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev