According to http://llvm.org/docs/CMake.html, “Shared libraries are not supported on Windows and not recommended in the other OSes”.
The problem is that static libraries have some limitations, especially when linked into multiple shared libraries, the global data of llvm could have multiple copies leading to undefined behaviors. This has caused much pains during my usage of llvm.
My questions are:
What are the reasons to not support shared libraries on Windows and not recommended in other OSes?
I've never tried building LLVM dlls on Windows, so this is all from
faulty mailing list memory.
You should be able to make a ginormous LLVM.dll that includes
everything you need just once. This should avoid your duplicate data
in depending DLLs problem. Someone else may know how to do this, or
you can search the list.
Splitting LLVM's internal libraries up into little dlls would speed up
incremental builds, but it's not easy. There's no way to blanket
export every symbol from a dll. Even if you did, I've heard there are
issues with exporting more than 2^16 symbols.
Adding targeted dllexport annotations won't work because non-Windows
developers (the majority) shouldn't be burdened with keeping them up
to date.
The problem is that static libraries have some limitations, especially when
linked into multiple shared libraries, the global data of llvm could have
multiple copies leading to undefined behaviors. This has caused much pains
during my usage of llvm.
My questions are:
1. What are the reasons to not support shared libraries on Windows and not
recommended in other OSes?
IIRC shared libraries are not recommended on other OSes because people
found that starting an executable that uses all those LLVM libraries is
slow, which hurts a lot when running the test suite, so the developers
tend to avoid shared libraries and they are not tested nor their
specific requirements considered while developing LLVM. IIRC (again)
long time ago I did some experimentation and running tests was about as
fast whith using shared libraries as with static ones on a Linux
machine.
Windows with the MSVC++ compiler does not support shared libraries at
all for the reasons given by Reid. For MinGW it is possible to create a
monolithic DLL (I did just that long time ago) or maybe DLL versions of
the static libraries. However, the caveats about being an untested
configuration are even stronger than on the other OSes.
2. Are there any plans to support shared libraries?
Actually, adding a LLVM_EXPORT macro would be positive for other environments, because you can then build LLVM
as a shared library with -fvisibility=hidden and use LLVM_EXPORT to only make public symbols visible. There are several
advantages to this, as noted here:
with some minor modifications I was able to build a DLL with Visual
Studio 11, which contained most LLVM-C functions in one DLL. However,
some manual work was necessary (e.g. build an export.def file), but
beside this it was quite easy.
Since Visual Studio isn't the IDE I'm used to, I can't tell exactly what
I have done, but since I was able to build it first for version 3.2 and
later for 3.3 it must have been quite simple. Just add dependencies to
the static libraries you want to use and add those functions to a .def
file you add in the projects settings. Other options are probably just
sugar.
Since I started with the solution, which was created by CMake it was
only possible to do it either for 32-bit or 64-bit, but since I only
needed 32-bit for now it's not a big issue. The mingw solution didn't
work for me somehow. Especially the DLL was too big (22 MB), when I
needed only some features (custom DLL is just 7 MB).
Actually, adding a LLVM_EXPORT macro would be positive for other environments, because you can then build LLVM
as a shared library with -fvisibility=hidden and use LLVM_EXPORT to only make public symbols visible. There are several
advantages to this, as noted here:
I agree, this would be useful even for other environments to solve the bloat that can happen by exporting all the symbols.
Adding targeted dllexport annotations won’t work because non-Windows
developers (the majority) shouldn’t be burdened with keeping them up
Maybe it just needs selling. If we can make the case that the
annotations cut down the time to run the test suite with the shared
library build, then maybe people will think it's worth the hassle.
