Discussion:
Unexpected static libraries in Windows build
(too old to reply)
Christian Ullrich
2016-12-06 20:59:21 UTC
Permalink
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
Leon Mlakar
2016-12-06 21:29:58 UTC
Permalink
Post by Christian Ullrich
, I have a number of static libraries (libboost_...-mt-1_62.lib) in
- 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
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
Christian Ullrich
2016-12-06 22:54:28 UTC
Permalink
Post by Leon Mlakar
Post by Christian Ullrich
, I have a number of static libraries (libboost_...-mt-1_62.lib) in
- 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
Loading...