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

Óscar Fuentes ofv at wanadoo.es
Sat Apr 7 18:45:09 PDT 2012


Michael Spencer <bigcheesegs at 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.




More information about the llvm-dev mailing list