Windows: auto_link.hpp incorrectly hardstops with error "Mixing a dll boost library with a static runtime is a really bad idea..."

[noloader@…]

I'm building a DLL which uses *STATIC* runtime linking. This means I am using the /MT switch, which defines "_MT" . Since I am building a DLL, "_WINDLL" is defined.

According to "/MD, /MT, /LD (Use Run-Time Library)", ​http://msdn.microsoft.com/en-US/library/2kzt1wy3(v=vs.90).aspx:

/MT - Causes your application to use the multithread, static version of the run-time library. Defines _MT and causes the compiler to place the library name LIBCMT.lib into the .obj file so that the linker will use LIBCMT.lib to resolve external symbols.

/MD - Causes your application to use the multithread- and DLL-specific version of the run-time library. Defines _MT and _DLL and causes the compiler to place the library name MSVCRT.lib into the .obj file. Applications compiled with this option are statically linked to MSVCRT.lib. This library provides a layer of code that allows the linker to resolve external references. The actual working code is contained in MSVCR90.DLL, which must be available at run time to applications linked with MSVCRT.lib. From the documentation, "_MT" is always defined, regardless of whether using static or dynamic runtime libraries). "_DLL" is defined when using dynamic runtime libraries.

Somehow, Boost is auto-configuring itself as if "_DLL" was defined in my dynamic link library (which it is not).

Perhaps the following would be a better test (sorry, I could not figure out the Boost specific stuff):

#if defined(BOOST_OS_WINDOWS) && defined(_MT) && !defined(_DLL) # define BOOST_OS_WINDOWS_STATIC 1 #elif defined(BOOST_OS_WINDOWS) && defined(_MT) && defined(_DLL) # define BOOST_OS_WINDOWS_DYNAMIC 1 #elif defined(BOOST_OS_WINDOWS) # pragma warning("Neither static nor dynamic runtime linking has been picked up") #endif

Note that the above does not touch upon DLL's and Import/Export headers - just the static and dynamic linking to the runtime

[John Maddock]

Duplicates #6644.