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

[Jakob Bornecrantz via llvm-dev]

On Thu, Dec 24, 2015 at 1:28 AM, Jakob Bornecrantz <wallbraker at gmail.com> wrote:
> On Wed, Dec 23, 2015 at 9:38 PM, Aaron Ballman <aaron at aaronballman.com> wrote:
>> On Wed, Dec 23, 2015 at 3:28 PM, Reid Kleckner <rnk at google.com> wrote:
>>> 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...
>
> We (not I) have rewritten the powershell script into a python
> script[1] and where hoping that we could commit that to LLVM and have
> it make a DLL during regular MSVC builds. And if possible shipping
> that DLL with the Windows package (and Windows snapshot builds[2]).
>
>>>
>>>>
>>>> > 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.
>>
>> Agreed.
>>
>>>>
>>>> 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.
>>
>> I think we're making the same point -- no consumer of LLVMSupport.lib
>> should expect to work if it doesn't use the stock set of library
>> dependencies. So use #pragma(lib) for everything that's not in that
>> set, but expect consumers to at least be using the stock set. Unless
>> you're suggesting we stick a #pragma(lib, user32) (et al) somewhere as
>> well?
>
> So ole32 and friends are added by default by cmake[3] which is why you
> are seeing them on the executables.
>
> Looking through the source I find advapi32.lib, psapi.lib, shell32.lib
> and dbghelp.lib are added via pragmas. Of these psapi.lib and
> dghelp.lib are not added to the default libs by cmake[3]. So just
> removing the pragmas would break the build without adding them back
> into the linking libs in cmake. Tho it would break all non-cmake based
> builds (that are using LLVM components) out there that don't happen to
> also link those libs. That is for versions < 3.8 non-cmake builds
> worked magically thanks to the pragmas.
>
> I have no real say in what path you should take here. Pragmas for me
> would be the easiest for me, since they just magically works, tho I
> appreciate the technical ugliness they present. That said if you
> remove the pragmas the list of libraries needed should be documented
> somewhere and probably also be returned by llvm-config.exe.
>
> If we keep the pragmas I guess we could have does link.exe add the
> libs by default as a basis for which pragmas we should add in. I can't
> experiment right now but user32, kernel32 and friends seems be
> included by default by link.exe or they are pragmas in the MSVC
> headers that the LLVM build picks.
>
> Thanks again for your time.

Ping?

Cheers, Jakob.

>
> [1] https://github.com/VoltLang/GenLLVMDLLPy/blob/master/GenLLVMDLL.py
> [2] http://llvm.org/builds/
> [3] https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Windows-MSVC.cmake