llvm dev - Dec 2015 - r250501 adds dependancy to ole32.dll on MSVC

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].
>>
>> 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
page).

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.

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.
>
> ~Aaron
>
>>
>> That commit breaks this commit, other users have also run into this
>> specific problem[3][4]. 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.
>>
>>
>> [1] http://www.llvmsharp.org/
>> [2] https://github.com/mjsabby/LLVMSharp/blob/master/GenLLVMDLL.ps1
>> [3]
http://stackoverflow.com/questions/33685644/missing-cotaskmemfree-when-building-llvm-example-on-windows
>> [4] https://groups.google.com/forum/m/#!topic/llvm-dev/Y3DYH0htGW4
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Link-against-OLE32.DLL-on-MSVC-build.patch
Type: application/octet-stream
Size: 719 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151223/7ff0983f/attachment.obj>

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].
>>>
>>> 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
> page).
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.

~Aaron
>
> 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.
>
>>
>> ~Aaron
>>
>>>
>>> That commit breaks this commit, other users have also run into this
>>> specific problem[3][4]. 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.
>>>
>>>
>>> [1] http://www.llvmsharp.org/
>>> [2] https://github.com/mjsabby/LLVMSharp/blob/master/GenLLVMDLL.ps1
>>> [3]
http://stackoverflow.com/questions/33685644/missing-cotaskmemfree-when-building-llvm-example-on-windows
>>> [4] https://groups.google.com/forum/m/#!topic/llvm-dev/Y3DYH0htGW4
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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>