Building LLVM as a shared library using Visual C++ 2010?

Hi,

From what I have seen on this mailing list and elsewhere, it would seem that it isn’t possible to build LLVM as a shared library using Visual C++. Still, I would imagine that quite a few people are or would be interested in it, so… is there any plan to support this any time soon? This, unless it’s already supported in some way or another which I am not aware of…? I have been able to build LLVM as a shared library using Autotools and GCC (through MinGW) on Windows (as well as on Linux and Mac OS X), so it would really be a shame if the same couldn’t be done using Visual C++…

Cheers, Alan.

The problem is that MSVC++ requires sprinkling
__declspec(dllexport/dllimport) all over the code, and we really don't
want to deal with maintaining that, as most developers have little to
no experience with Windows DLLs.

There may be a work around for this, which I partially implemented in
the past. You have a script which automatically generates a .def file
for all the public functions in all the object files. My attempt did
not work because I tried to export by ordinal, but that only supports
up to 2^16 symbols. It may work without exporting by ordinal, but I
never tried it.

- Michael Spencer

Michael Spencer <bigcheesegs@gmail.com> writes:

The problem is that MSVC++ requires sprinkling
__declspec(dllexport/dllimport) all over the code, and we really don't
want to deal with maintaining that, as most developers have little to
no experience with Windows DLLs.

Is the maintenance the only issue? If yes, maintenance could be
delegated those who actually use the feature, as most Windows-related
stuff is since the beginning of LLVM.

BTW, you don't put __declspec(dllexport) / __declspec(dllimport) on the
code, but macros that alternatively expand to those declspecs depending
on if the library is being compiled or referenced.

IIRC, some LLVM developers regarded those declarations as unwanted
noise, but maybe now that Windows has a somewhat higher profile on the
LLVM community the noise could be tolerated if dlls are important enough
for the Windows users. On addition, those declarations could be a good
thing on Linux too, instead of exporting everything on the shared
libraries, which is the current default.

There may be a work around for this, which I partially implemented in
the past. You have a script which automatically generates a .def file
for all the public functions in all the object files. My attempt did
not work because I tried to export by ordinal, but that only supports
up to 2^16 symbols. It may work without exporting by ordinal, but I
never tried it.

Yeah, I tried that too. AFAIK the 2^16 symbol limitation on the VS
linker applies to .def files in general, not just when exporting by
ordinal. One problem I found was to differentiate the relevant stuff
from the junk while deciding what to put on the .def file. I find it
hard to believe that any LLVM library exports 65000 symbols. Maybe
fine-tuning the symbol filtering the .def files could be used regardless
the 2^16 limit, altough generating those .def files would never be as
reliable as putting the declarations on the source code, IMO.

It seems to be that LLVM doesn’t make sense as a shared library. The surface area of the interface is massive, and in constant flux. I would think in real world situations, a domain specific interface with a more focused public interface would the right solution.

What about only exporting the C interface? I think this pretty much
covers all the people like me who want to call the LLVM API from a VM
or interpreter (python, .NET, Java bindings...). Am I right in
thinking this is the biggest use case for building LLVM as a DLL?

-Keith

There are a variety of "real world situations," some of them would benefit from
shared-library packaging and some would not. Say you're building a set of
tools for internal deployment in your large-ish organization.
Factoring out the
Clang/LLVM bits into a shared library can reduce memory footprint when running
multiple tools, reduce disk footprint which therefore reduces
antivirus overhead,
and so forth. The constant-flux aspect of the interface mostly means you can't
deploy the libraries separately from the tools that use them, but so what?
Logistically that's no different than how you would deliver static-linked tools.

Pogo

I wasn’t say that deploying LLVM within a shared library didn’t make sense, just that the interface to that shared library should be targeted at the application domain that it is being used within.