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

[Nick Lewycky]

Óscar Fuentes 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.

I think that premise needs to be retested. I don't doubt that we have a 
very large number of symbols, but I wouldn't be so sure that it still 
results in a large load time on modern hardware.

> 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.

There's very very little that we don't want exposed. LLVM is by design a 
framework where everything is reusable.

But there are two things you can look at. The first is that g++ doesn't 
(didn't?) properly support anonymous namespaces. Things in anonymous 
namespaces don't need to have symbols created for them. Second, LLVM 
classes are littered with VISIBILITY_HIDDEN.

Everything else is public.

> 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?

I don't think it matters much to the existing developer base. The people 
who are likely to get very excited about this are the distributors 
trying to package LLVM for their Linux distro.

Nick