Unexpected static libraries in Windows build
Hello, I have a question about compiling Boost (1.62.0) itself on Windows, with Visual Studio 2015. I want to build DLLs only, but after I run .\b2 link=shared runtime-link=shared [...] install , 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 The first four also exist as the DLLs I expected to get. From testing some previous Boost releases, it seems that the number of unexpected static libraries increases over time (1.58 only produces two, and more appear with the versions in between that and 1.62). Why are these static libraries built in a shared/shared configuration? Do I need to keep them, or are they some kind of temporary build artifact (used to build others, perhaps)? I have looked through the documentation, mailing list archive, bug tracker, etc., but could not find anything on the subject. If I have not looked hard enough, any pointers will be welcome. I even looked at b2's dependency graph (-d +12), and from that, it appears they are top-level dependencies, but I cannot figure out where _any_ top-level dependencies are defined, let alone these. Thanks for any hints, -- Christian
, 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
The first four also exist as the DLLs I expected to get. 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
On 06.12.2016 21:59, Christian Ullrich wrote: linker. You don't need them to just run a program that loads .dll. But then again, I'm no expert in MS and of course may be wrong. Cheers, Leon
* 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
participants (2)
-
Christian Ullrich -
Leon Mlakar