[boost] [filesystem] [system] Suddenly, dynamic linking by default

Subject: [boost] [filesystem] [system] Suddenly, dynamic linking by default
From: Lars Viklund (zao_at_[hidden])
Date: 2012-04-29 09:05:44

Hello list.

I have a habit of tracking trunk to find out if there's any strangeness
or mistakes done on the platforms I target.

A while ago I encountered some strange linking errors on some of my
projects, which in the end turned out to be because for some
reason, Boost.Filesystem and Boost.System now attempt to be dynamically
linked by default, both symbol-decoration-wise and auto-link
filename-wise.

I happened to have some older shared libraries from an older trunk
version lying around, so they were suddenly and unexpectedly picked up
instead of my fresh static libraries.

Even without my library hygiene deficiencies, the decision (which I have
yet to see a rationale or announcement about) will cause a lot of
problems.

Why is it that System/Filesystem suddenly default to dynamic linking?
Are there problems about linking statically? Why are there then static
libraries built at all? Is this just some personal preference of the
author that goes contrary to the general approach of Boost?

Such choices have _massive_ impacts on consumers of the code, they
should not be made lightly and if there is a really concrete need to do
so, why is it not documented and thoroughly explained?

Linking dynamically requires you to deploy the Boost DLLs to the end user,
which prevents any plugin-like deployment, as they tend to require a
single self-contained shared library with no dependencies, which
implies linking to a static language runtime of choice.

Dynamic linking of Boost means that you need to share a CRT between the
project and Boost, which implies that the only CRT choice is the dynamic
one, which prevents many deployment scenarios, as you have to deploy
_that_ as well to the end user, either as a redistributable install or
as a private deployment.

This also has an impact on code size, as there is no dead-code
elimination possible when the code resides in a DLL, you have to ship
_all_ of the library even if you use a few convenience functions.

For one of my projects (an extension to a popular music player), this
would inflate its size many times for each and every download, as the
software is deployed as a single ZIP archive through automatic update
services.

Additionally, the autolink macros to force symbol decoration and linking
for a static link are undocumented in the Boost.Config table [1], which
explicitly states that all libraries that can be statically linked will
be statically linked. There is no mention of libraries that arbitrarily
decide to go dynamic, just that some libraries are only available in
dynamic form.

For future reference for anyone finding this in archives, the
undocumented, and in this case required, macros to force a static link
and symbol decoration are:
BOOST_<WHATEVER>_STATIC_LINK or
BOOST_ALL_STATIC_LINK

[1] http://www.boost.org/doc/libs/1_49_0/libs/config/doc/html/index.html#boost_config.configuring_boost_for_your_platform.user_settable_options

-- 
Lars Viklund | zao_at_[hidden]