Subject: Re: [Boost-build] Problem running exe after linking to system library
From: Lars Viklund (zao_at_[hidden])
Date: 2012-07-23 09:52:48
On Mon, Jul 23, 2012 at 02:40:31PM +0100, Paul A. Bristow wrote:
> Using boost-trunk, I am trying to run a library that uses chrono, that in turn uses the Boost system
> "Can't start because the program boost_system-vc100-mt-gd-1_50.dll is missing..."
> Linking to lib file: boost_system-vc100-mt-gd-1_50.lib
> Multi-threaded Debug DLL (/MDd)
This message is because the DLL is not in the PATH or the working
directory. The Boost.Build scripts that the tests normally use most
probably ensures that the PATH includes the dynamic libraries needed
when running the test.
> (If I use in the compile options what I expect to use : static - /MTd then I get the #error :
> "Mixing a dll boost library with a static runtime is a really bad idea..."
The way you link to the CRT is utterly unrelated to the way you link to
a Boost library. The part of the filename that determines the runtime
used is the -sgd- bit, where -s- means static CRT, lack of -s- means
dynamic CRT, -gd- means debug CRT, lack of -gd- means release CRT.
As for the error, it's very annoying, but also slightly true, as linking
Boost dynamically but with separate instances of the static runtime in
each module would lead to that no C++ entities can be shared across the
> (Why it is looking for the .dll when the build says linking to the .lib???)
Because you're linking against the _import_ library for Boost.System.
For Boost on Windows, the static library is named like:
and the import library for the corresponding dynamic library
boost_whatever-*.dll is named like:
Both are named .lib, as that's what you link against on MSVC no matter
whether you want a static library or an import library for a DLL.
> All the system .dll and .lib version appear to exist at the default boost-trunk/stage/lib place:
> So I concluded that all the files are definitely present at the right places.
Those are the dynamic library and the import library for it.
> What I eventually discovered I was doing wrong was not to include the macro call
> #define BOOST_SYSTEM_STATIC_LINK 1
This was reported in the past in that Filesystem and System was
accidentally changed to link dynamically by default, having users rely
on those underdocumented macros to restore sanity.
This was fixed on trunk once and if this has re-appeared, I severely
doubt the sanity of whoever keeps changing this oblivious to history.
> I find this confusing. It appears that autolinking is not working as I would expected.
> Am I doing something else wrong?
Are you using the real Boost trunk or some eternally broken/lagged Git
mirror like the gh:ryppl/boost-svn one?
-- Lars Viklund | zao_at_[hidden]
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk