[odb-users] Problem - Using ODB inside a DLL

[Boris Kolpackov]

Hi Cuong,

Cuong Tran <vaioinman at googlemail.com> writes:

> Today, I have the first chance to revisit the issue. I compile your example
> project under XP Pro. I only changed the server address, db name and user
> name. The issue is still there, expectedly, but I learn a few things.

Ok, now I have been able to reproduce this problem and figured out what's
going on. As it turns out, the __declspec(thread) storage-class modifier,
which libodb uses, does not work properly on Windows XP/Server 2003 and
earlier, if the code that uses it is loaded dynamically. The comment at
the bottom of this page confirms this:

http://msdn.microsoft.com/en-us/library/9w1sdazb(v=VS.80).aspx

I don't think it is a good idea to disable its usage by default since
it is potentially much faster than the TlsGetValue()/TlsSetValue() Win32
calls. So I have added the following note to the libodb INSTALL file with
instructions on how to disable it manually:

"
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.
"

I tried this on the test and everything works fine. Can you give it a
try and see if it works for you?

And thanks for reporting this!

Boris