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

[Scott Graham]

Hi

I'm not sure that it meets your needs, but in making C# bindings[1], 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
public/internal anyway.

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.

scott

[1] 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
> use.
>
> 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?
>
> --
> Oscar
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>