[llvm-dev] r250501 adds dependancy to ole32.dll on MSVC

Reid Kleckner via llvm-dev llvm-dev at lists.llvm.org
Wed Dec 23 12:28:03 PST 2015


On Wed, Dec 23, 2015 at 11:25 AM, Aaron Ballman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Wed, Dec 23, 2015 at 1:55 PM, Jakob Bornecrantz <wallbraker at gmail.com>
> wrote:
> > On Wed, Dec 23, 2015 at 5:49 PM, Aaron Ballman <aaron at aaronballman.com>
> wrote:
> >> On Wed, Dec 23, 2015 at 11:29 AM, Jakob Bornecrantz via llvm-dev
> >> <llvm-dev at lists.llvm.org> wrote:
> >>> I'm building on Windows x64 using cmake, Ninja and VS 2013 express on
> Windows 7.
> >>>
> >>> So I have been using the LLVMSharp method on getting a usable loadable
> >>> LLVM.dll[1][2].
>

One day, I would like to make it easier to make LLVM.dll...


> > Further investigation show that for the MinGW build OLE32 is added to
> > the dependencies for LLVMSupport.lib in the CMakeLists.txt file, there
> > are a couple of other libraries added as well. This lead me to find
> > that those where added for the MSVC build with a pragma(lib, xx), so I
> > added such a pragma for OLE32 and that fixes my script that is
> > generating LLVM.dll, will also fix other peoples problems with OLE32
> > missing as well.
>
> Generally speaking, static libraries like LLVMSupport are just an
> archive of a bunch of compiled object files, and whatever ultimately
> consumes that library is responsible for providing external
> definitions. So, for instance, clang.exe consumes LLVMSupport.lib and
> so it also links in OLE32. I believe that we usually only use
> #pragma(lib) to signal that non-standard libraries need to be linked
> in, otherwise every source file in an archive would wind up with an
> unwieldy number of pragmas for all its imports, or you would have to
> manually maintain that list in some common header file. I don't think
> that the pragma(lib) for advapi32.lib should be there either, FWIW,
> but I don't know that we've ever had a hard-and-fast rule for this
> sort of thing.
>

Sure, but the fact that static libraries can't encode their dependencies
has always been an annoying missing feature, not something that we want to
follow if we can avoid it.


> I'm not opposed to this patch, per se, but it feels like a slippery
> slope as to what makes the cut and what does not. I would rather see
> *less* non-standard pragma usage instead of more.
>

For these kinds of DLLs that are available on all modern versions of
Windows, I think it's perfectly reasonable to use the 'pragma comment lib'
auto linking mechanism. Realistically, no consumer of LLVMSupport.lib is
going to be surprised if it needs ole32.dll.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151223/e5e04ff6/attachment.html>


More information about the llvm-dev mailing list