Library Naming

One of the things I find the most confusing about the Boost libraries is the naming convention. Boost libraries can have a strict naming convention. To get an idea of what I'm talking about go to the Boost libraries location on your system (keep in mind today I'm working with Visual Studio in Windows). If you look at the directory, you might see:

boost_bzip2-vc80-mt.lib
boost_bzip2-vc80-mt-1_45.dll
boost_bzip2-vc80-mt-1_45.lib
boost_bzip2-vc80-mt-gd.lib
boost_bzip2-vc80-mt-gd-1_45.dll

boost_bzip2-vc80-mt-gd-1_45.lib

boost_bzip2-vc90-mt.lib
boost_bzip2-vc90-mt-1_45.dll
boost_bzip2-vc90-mt-1_45.lib
boost_bzip2-vc90-mt-gd.lib
boost_bzip2-vc90-mt-gd-1_45.dll

boost_bzip2-vc90-mt-gd-1_45.lib

boost_bzip2-vc100-mt.lib
boost_bzip2-vc100-mt-1_45.dll
boost_bzip2-vc100-mt-1_45.lib
boost_bzip2-vc100-mt-gd.lib
boost_bzip2-vc100-mt-gd-1_45.dll

boost_bzip2-vc100-mt-gd-1_45.lib

And these are only the libraries regarding bzip2 functionality in Boost! It's an awful lot to take in. Two main questions arise: How do I dissect the filenames? What file do I link against?

How to Dissect File Names

First, look at the boost documentation. [1] This highlights the rules so I won't cover the name of the boost library.

Compiler Used
Example: vc80, vc90, vc100
Obviously the compiler used to build a project should match. If the developer is building an application using Visual Studio 2010 then the appropriate version of the library to use is vc100. 

MultiThreaded?
Example: mt
Should the library being used use the multi-threaded version. If you are wondering whether or not your project is being built with multithreaded support in Visual Studio do the following:
1) Right click on a project.
2) Select properties
3) Under C/C++ select Code Generation.
4) Take note of the Runtime Library flag, it will be /MD, /MT, /MTd, /MDd.

Interoperability Flag
Example: gd
Take a look at the table in the reference material [1]. For the example above you'll see that we reference gd in some of the libraries; this means that we are using the debug version of the runtime and a debug version of the project. This is also a great place to look for static library functionality. 

What file do I link against?

This is where I believe Boost does too much for the developer. Boost uses a feature called "Auto-Linking" in Windows [2]. Auto-linking uses "special code" to link the correct library into your project. This is at odds with the method in Linux which is simply to find the right library and link it. The inconsistency is a challenge when writing make generator tools such as premake4 because the premake4 files have to execute different code on Linux vs. Windows. At that point why do we even bother with cross-platform make tools?

There is hope for those writing cross-platform make tools; boost allows us to turn the Auto-linking feature off through defining "BOOST_ALL_NO_LIB" [3]. This is a pretty good solution and I'm not surprised it exists.

Conclusion

Linking libraries in Boost can be a mess and neater than anything. With the myriad of different configurations in the library binaries it's nice that the authors have provided a way to automatically link the dependencies on Windows. The messy part of linking in Boost occurs in Linux where we don't have the option to Auto-Link. In Linux we must pay attention to the configuration of the project we are building that uses Boost and choose the appropriate link targets using the dissected Boost library filenames.

References

[1] - http://www.boost.org/doc/libs/1_53_0/more/getting_started/windows.html#library-naming

[2] - http://www.boost.org/doc/libs/1_41_0/more/getting_started/windows.html#link-your-program-to-a-boost-library

[3] Boost Headers, boost/config.hpp, http://www.boost.org/doc/libs/1_53_0/libs/config/doc/html/index.html#boost_config.configuring_boost_for_your_platform.user_settable_options

[4]