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

[Aaron Ballman via llvm-dev]

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...
>
>>
>> > 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?

~Aaron