[llvm-dev] r250501 adds dependancy to ole32.dll on MSVC
Aaron Ballman via llvm-dev
llvm-dev at lists.llvm.org
Wed Dec 23 11:25:13 PST 2015
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
>>> This have worked out of the box before so it is a regression, I
>>> tracked it down to commit r250501.
>> Oh, interesting, CoTaskMemFree() is from OLE32. That's a typical MSVC
>> link library, so I'm not certain why that is not included already in
>> the project. Indeed, every executable target I check has OLE32.dll in
>> its linker input. Is this an issue with whatever is generating
>> LLVM.dll for you, or is there a specific target that is missing this
>> linker input?
> Thanks for the reply.
> I have to warn that I am not a windows dev and I'm coming from the
> Linux world so my knowledge is limited.
> I have attached a patch that fixes my issue (apologies for the format,
> only have a git checkout of llvm handy and I could not get git diff or
> git format-patch to output a svn formatted patch as per the developer
This patch is one approach we could take for the issue, but I would
like to better understand the problem first.
> 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.
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.
> Some info on the script, it uses dumpbin to get a list of symbols
> which (filtered to only include ones starting with LLVM*) from all of
> the .libs produced by the build. These are then merged and linked into
> LLVM.dll using the filtered list as a export file.
> Cheers, Jakob.
>>> That commit breaks this commit, other users have also run into this
>>> specific problem. I tried looking into the CMakeLists.txt for
>>> LLVMSupport.lib and add ole32 as a dependency for it, but that didn't
>>> seem to stick. My cmake-fu is too weak. IIRC windows lib files can
>>> track library dependencies so that should work.
>>> I check llvm-config.exe and it does not printout ole32.lib when given
>>> the --system-libs flag or --ldflags argument.
>>> Carrying around a hack to add ole32.lib to the discrepancies will work
>>> for me but that will just mean more users will run into it.
>>> Any advice on how to proceed is greatly welcome, thanks.
>>> Cheers, Jakob.
>>>  http://www.llvmsharp.org/
>>>  https://github.com/mjsabby/LLVMSharp/blob/master/GenLLVMDLL.ps1
>>>  http://stackoverflow.com/questions/33685644/missing-cotaskmemfree-when-building-llvm-example-on-windows
>>>  https://groups.google.com/forum/m/#!topic/llvm-dev/Y3DYH0htGW4
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
More information about the llvm-dev