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

Óscar Fuentes <ofv@wanadoo.es> writes:

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.

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.

I have just realised that I directly replied to Michael rather than the
mailing list (!!), but it was to say the same as Óscar with regards to the
use of a macro. In fact, I am thinking of taking this approach for the
classes that I need in my project. Still, it will mean 'hacking' the code
myself, and I really wish I didn't have to go that route, but... what other
choice do I have if I want to use MSVC?...

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.

FWIW, using MinGW, I end up with a DLL with 13,320 symbols. Still, I agree
with Óscar, this wouldn't be as reliable as using a macro (not to mention
that maintenance could be a bit of a nightmare).

Alan

Óscar Fuentes <ofv@wanadoo.es> writes:

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.

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.

I have just realised that I directly replied to Michael rather than the
mailing list (!!), but it was to say the same as Óscar with regards to the
use of a macro. In fact, I am thinking of taking this approach for the
classes that I need in my project. Still, it will mean ‘hacking’ the code
myself, and I really wish I didn’t have to go that route, but… what other
choice do I have if I want to use MSVC?..

Until this is resolved, why not statically link?

From: Justin Holewinski [mailto:justin.holewinski@gmail.com]

I have just realised that I directly replied to Michael rather than the
mailing list (!!), but it was to say the same as Óscar with regards to

the

use of a macro. In fact, I am thinking of taking this approach for the
classes that I need in my project. Still, it will mean 'hacking' the code
myself, and I really wish I didn't have to go that route, but... what

other

choice do I have if I want to use MSVC?...

Until this is resolved, why not statically link?

Because everything in my (Qt) application is a plugin, so LLVM is a plugin
which can be used by other plugins that need LLVM's functionalities. This
all works fine with MinGW on Windows, and gcc on Linux and Mac OS X, but now
I need to get things to work with MSVC on Windows and I am kind of stuck.

Alan