Add note on disabling __declspec(thread) usage if loading libodb DLL dynamically

Windows XP/Server 2003 do not support this.

1 files changed, 15 insertions, 3 deletions

diff --git a/INSTALL b/INSTALL
index 8d6b225..0e6dcc6 100644
--- a/INSTALL
+++ b/INSTALL
@@ -46,7 +46,7 @@ you are using. Once the solution is open, select the desired build
 configuration (Debug or Release) and platform (Win32 or x64) and build
 the solution.
 
-The resulting 32-bit DLLs and import libraries are placed into the 
+The resulting 32-bit DLLs and import libraries are placed into the
 libodb\bin\ and libodb\lib\ directories, respectively. Similarly, the
 64-bit DLLs and import libraries are placed into libodb\bin64\ and
 libodb\lib64\. The Release versions of the import libraries are named
@@ -60,10 +60,22 @@ Win32:
 
   Include:    ...\libodb
   Library:    ...\libodb\lib
-  Executable: ...\libodb\bin    
+  Executable: ...\libodb\bin
 
 x64:
 
   Include:    ...\libodb
   Library:    ...\libodb\lib64
-  Executable: ...\libodb\bin64    
+  Executable: ...\libodb\bin64
+
+Note also that by default libodb uses the __declspec(thread) storage-class
+modifier for TLS support. This mechanism is known not to work correctly on
+Windows XP/Server 2003 and earlier versions of Windows if a DLL that uses
+this modifier is loaded dynamically. If you are planning to link libodb to a
+DLL that will be loaded dynamically (e.g., delay loading, COM DLL, explicit
+LoadLibrary() call, etc), then you will need to comment out the definition
+of the ODB_THREADS_TLS_DECLSPEC macro in the odb\details\config-vc.h file
+prior to building libodb. On the other hand, if you plan to link libodb
+directly to an executable or another DLL that will be linked directly to
+an executable or if you only need to support Windows Vista/Server 2008,
+then you don't need to make this change.