static variables & LIB problem

[sedj]

Hi,

This is a little complicated, so please bear with me.

I have two DLLs, and a (common) static library (LIB).

Each DLL is linked statically to the "common" lib.

Within the static lib, there is a class which has a few static member variables, and a static method.

I also have a binary, that, depending on the input, will call one of the DLLs, which in turn will call the static class method in the "common" lib.

the code is also cross-platform, and when compiled in Linux I am seeing different behaviour in respect to the static variables.

In Linux, each of these DLLs, and the "common" lib are compiled as Shared Objects - with the two *DLL* type shared objects linking to the single compiled "common" shared object (or lib in Win32 land).

In Linux, there is only one instance of the static member variables - but in Win32 there are two (one for each of the static libs linked to the DLL).

Now I understand why this is the case in Win32, but I have no idea how to get the same behaviour in Win32 as I do in Linux - in effect having only one static instance of this "common" class's variables.

The classes in the "common" lib do not export their functions as you would in a DLL, and I do not wish to actually do this - so I cannot compile the "common" library as a DLL.

Has anybody any idea how I can achieve having only one instance of static members within the process and called DLLs (without a coding work-around and passing in the various bits and bobs via the DLL functions) ?

In Win32, I am using Visual Studio 2003. All code is a mixture of pure C and C++ (ie no .NET / managed C++ etc).

Here's hoping !

Cheers

--------------------------------------------------
Free Java/J2EE Database Connection Pooling Software

http://www.primrose.org.uk

 

[xwb]

Is common a .so or a .a?

.so = .dll + .lib
.a = .lib only

On Unix, the .so can be built standalone but on windows, it has to resolve everything. It does this with a .lib which is created when building the DLL. This has a jump table to the routines and is used by other DLLs and exes for linking.

Say your DLLs are xxx.dll and yyy.dll and they both rely on common. On windows, the problem can be tackled in one of two ways

a) make common a dll. This will create common.lib and common.dll. When linking xxx.dll and yyy.dll, put common.lib in its input list.
b) leave common as a lib. This means that you just have common.lib and nothing else. Include common.lib in xxx.dll and export its functions in the xxx.def file. When linking yyy.dll, add xxx.lib to its input dependency. This means that yyy.dll is depenent upon xxx.dll.

 

[sedj]

The linux common is a .so

I tried your option "a)", but VS7 is not generating a .lib file. This is because I am not exporting any functions. If I do, like this :

extern "C" {
   __declspec( dllimport ) void blablabla();
}

then a .lib and .exp are generated.

But the problem is, I don't want to export any functions like this - as the "common" lib is made up of 50 or so classes, with many many methods !

Any ideas ?

--------------------------------------------------
Free Java/J2EE Database Connection Pooling Software

http://www.primrose.org.uk

 

[xwb]

There are two ways of exporting symbols on MS - both quite painful.

One is __declspec(dllexport) in the declaration and __declspec(dllimport) in usage. What we normally do is have it as a macro which defines it as dllexport only if some file included by all the library modules has been defined.

The other way is to create a .def file with all the symbols to be exported. This is quite painful, especially with the name mangling. Having said that, this method is more flexible if you are releasing the libraries to customers and expecting to put in hot fixes. Every exported function has an ordinal number and that does not change unless you change the .def file. With __declspec, it generates its own ordinals and that can change from one link to the next.