Re: [Boost-users] Unexpected static libraries in Windows build

Subject: Re: [Boost-users] Unexpected static libraries in Windows build
From: Christian Ullrich (chris_at_[hidden])
Date: 2016-12-06 17:54:28

* Leon Mlakar wrote:

> On 06.12.2016 21:59, Christian Ullrich wrote:

>> , I have a number of static libraries (libboost_...-mt-1_62.lib) in
>> the lib directory. Specifically:
>>
>> - system
>> - chrono
>> - timer
>> - unit_test_framework
>> - test_exec_monitor
>> - exception

> As far as I recall you need .lib file to accompany dynamic library
> (.dll) in order to link you code against .dll in compile time - this is
> not a static library, it only contains declarations needed by the
> linker. You don't need them to just run a program that loads .dll.

Correct in principle, but this is something else. The msvc build can 
produce three kinds of libraries:

- boost....dll, the shared library (with link=shared)
- boost....lib, the import library for the DLL (with link=shared)
- libboost....lib, the static library (with link=static)

So when I only build link=shared, for most of the Boost libraries I get 
the two I expect: the DLL and its import library. However, for the first 
four above, I get these two _and_ the static libboost*, and for the last 
two, I _only_ get the static one.

In these latter cases, I suspect they happen because they simply do not 
work as DLLs (I could understand that for exception, because while 
you're handling an exception, you probably don't want to load any 
additional DLLs), but the other four are a mystery to me.

Some context: I noticed this behavior when building Boost through vcpkg 
(https://github.com/Microsoft/vcpkg/), because it splits the files 
produced by the shared and static build into separate directories. When 
I built earlier Boost releases by hand, I always did the full set 
(link=shared/runtime-link=shared, static/shared, static/static) into the 
same location, and that may explain why I never noticed that any static 
libs appeared "early".

vcpkg's Boost build process also currently has a bug that clobbers the 
import libraries for the aforementioned "first four" by replacing them 
with the static libs. Since the vcpkg developers also don't appear to 
know why the statics are built at all, I don't want to sign off on their 
proposed fix (simply discarding the stray statics) without better 
understanding the issue.

I'm worried chiefly because I have convinced myself that the statics 
contain some symbols that the DLLs don't have, and vice versa. So as far 
as I know, this may actually be a Boost bug that results in incomplete 
libraries.

tl;dr: No, that's not it, and I have to keep asking because I don't know 
whether I don't know something.

-- 
Christian