llvm dev - Apr 2012 - [LLVMdev] 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120407/c8716979/attachment.html>

On Fri, Apr 6, 2012 at 6:15 PM, Alan Garny <agarny at hellix.com>
wrote:
> 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 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.

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.

On Fri, Apr 6, 2012 at 6:15 PM, Alan Garny <agarny at hellix.com> wrote:
> 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.****
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120413/0a07bbb6/attachment.html>

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

On Sat, Apr 7, 2012 at 8:26 PM, Michael Spencer <bigcheesegs at gmail.com>
wrote:
> On Fri, Apr 6, 2012 at 6:15 PM, Alan Garny <agarny at hellix.com>
wrote:
>> 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
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


-- 
keithsheppard.name

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

On Fri, Apr 13, 2012 at 9:59 AM, Nathan Jeffords
<blunted2night at gmail.com> wrote:
> 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.
>
> On Fri, Apr 6, 2012 at 6:15 PM, Alan Garny <agarny at hellix.com>
wrote:
>>
>> 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.
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>