* 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