I think it is an error when an end-user uses a Boost library which may need a separate DLL built, never uses a function/class which is implemented in that separate DLL, and yet the Boost header files for that library bring in autolinking. Is this considered an error in the development of a Boost library ? What is invariably happening when this situation occurs is that a header file which has autolinking code ( #pragma comment(lib,"somelib") in VC++ for example ) is included for functions/classes which are not in the autolinked library at all. This is because the Boost developer has not placed all the autolinked functionality for a particular library in its own header file, preferring instead to place declarations in logically related header files. While the latter is understandable as far as organization of a library is concerned it destroys the ability of that library to enforce autolinking only when the end-user requires it. Despite the fact that library developers, of Boost libraries which are not completely header only, go for orthogonality when creating their header files I would like to see things changed so that using a library which does not require the built library to be linked in when using functionality of that library does not being in autolinking. I realize that there are macros of the BOOST_SOMELIB_NO_LIB around to turn off autolinking but this places a burden on the end user which should not be there. I was recently using the date/time library for the first time, used functionality which I was pretty sure was not in the built library based on the documentation, yet autolinking code was brought in to force me as an end-user to specify the location of the import library. When I defined BOOST_DATE_TIME_NO_LIB in my project settings, everything linked fine without specifying the import library, so obviously the DLL was not needed. Nobody wants to distribute a shared library with their code when it is unnecessary.