Even with BOOST_ALL_NO_LIB defined, VS14 linker looks for mt-s variant

[emonette123@…]

We do not use the default library names for boost. In fact, we only compile filesystem, system and date_time libraries. We define BOOST_ALL_NO_LIB, compile with b2 and rename the libraries to filesystem.lib, system.lib and date_time.lib for a static link with static linkage to standard lib. This worked for us for many Boost lib versions and different Visual Studio versions. With Boost 1.61 and Visual Studio 2015 (vc14), we receive the following error when linking a project to our renamed filesystem.lib for example:

LINK : fatal error LNK1104: cannot open file 'libboost_filesystem-vc140-mt-s-1_61.lib'

No matter if we even specify --layout=sytem as a build option to generate libboost_filesystem.lib: we still get a linkage error on the complete -vc140-mt-s-1_61 variant.

Leaving both renamed libraries and boost named libraries in our library path fixes the issue.

Why is Visual Studio 14.0 linker still using autolink features with boost 1.61, even though we specify boost not to use autolink (ie, we define BOOST_ALL_NO_LIB).

We also get a macro redefinition warning when we define BOOST_ALL_NO_LIB in user.hpp header. It looks like it is correctly defined, but linker will still look for the -vc140-mt-s-1_61 variant of the library.

I tried about all possibilities when compiling with b2, to no avail.

[anonymous]

You have to define BOOST_ALL_NO_LIB when you compile your program, not when you compile Boost.

[anonymous]

Duh! I understand what happened now: I was not responsible for distributing boost include directory and for compiling it that time... So boost was correctly compiled with the BOOST_ALL_NO_LIB define, but in the distributed headers, user.hpp in config was not modified to include BOOST_ALL_NO_LIB.

Hence the difference between how boost library is compiled and how code using the library is.

There is no bug here, just a stupid pilot error.

This ticket can be closed.