DLL With Static Library Initialization Conflict

[Robert A Riedel]

I have an application that requires a DLL and an executable that uses the
DLL, both of which were implemented in Visual C++ using unmanged code. Both
the executable and the DLL are linked with functions that are stored in a
static library. During initialization of the executable, classes and static
globals within functions linked from the static library appear to be
initialized twice, once when the executable initializes the run-time code,
and once when the DLL initializes the run-time code. This dual
initialization is not always benign and I am at a loss of how to stop it.

Presumably, there must be some method of including functions from a static
library once, and once only, either in the DLL or in the referencing
executable.

Perhaps this situation has been encountered before. If so, any suggestions
would be appreciated.

--
======================================================================
======================================================================
==
== Bob Riedel
== Beckman Coulter, Incorporated
== PO Box 8000 W-529
== 200 S Kraemer Blvd
== Brea CA 92822-8000
==
== Email 1: (e-mail address removed)
== Email 2: (e-mail address removed)
==
==
== The opinions expressed are my own, and do not necessarily represent
== those of Beckman Coulter, Inc.
==
======================================================================
======================================================================
==
== "Effective education is the key to successful democracy."
==
== "Criticizing the actions of others offers so little risk, and
== requires so little effort that it is, without exception, the tool
== of the lazy and of the foolish -- who have neither the intelligence
== to discover, nor the discipline to pursue, a realistic
== alternative."
==
======================================================================
======================================================================

 

[Doug Harrison [MVP]]

I have an application that requires a DLL and an executable that uses the
DLL, both of which were implemented in Visual C++ using unmanged code. Both
the executable and the DLL are linked with functions that are stored in a
static library. During initialization of the executable, classes and static
globals within functions linked from the static library appear to be
initialized twice, once when the executable initializes the run-time code,
and once when the DLL initializes the run-time code. This dual
initialization is not always benign and I am at a loss of how to stop it.

Presumably, there must be some method of including functions from a static
library once, and once only, either in the DLL or in the referencing
executable.

Perhaps this situation has been encountered before. If so, any suggestions
would be appreciated.

I can think of two solutions. I'll start with the more general one.

As your EXE and DLL are linking statically to the library, they each get
their own, private copies of the library's code and data. For them to share
this library's code and data, you will have to turn it into a DLL, which
they both link to. A similar situation exists with the CRT. Modules which
link statically to it have independent CRT state, including heap, file
descriptors, errno, and so on, which creates module boundary problems in
which memory allocated by the DLL can't be freed in the EXE, FILE*'s can't
be passed between modules, and so on. Linking everyone to the same CRT DLL
avoids these problems and makes your program act much more like a statically
linked program.

Alternatively, you could have your DLL link to the static library and define
a forwarding interface for use by the EXE, which would no longer link to the
static library. Of course, this could be very inconvenient.

 

[Robert A Riedel]

This is a helpful response. It is the solution that I expected, even though
I had hoped to avoid it. Thank you for the reply.

 

[Robert A Riedel]

While attempting to implement this suggestion, I am having difficulty
interpreting a semanic issue with respect to the __declespec(
dllexport/dllimport ) keyword. Suppose for example a class is declared in a
header file:

//Header file 'a.h' :

#ifndef API
#define API __declspec( dllimport )
#endif

class
API
a
{
void do_some_stuff( void ) const ;
} ;

// Implementation file:

#define API __declspec( dllexport )

#include "a.h"

namespace {

struct B { int n ; } ;

B _b ;

} // END:: anonymous namespace

a::do_some_stuff( void ) const
{
_b.n++ ;
}

// END implementation file.

Will the static global _b declared in the anonymous namespace be properly
initialized by the CRT when the DLL startup code runs without specifying any
specific attributes?

If I understand the way a DLL should work, I would claim that static global
_b in the anonymous namespace would be instantiated in the DLL's private
segment when a process attaches.

Is this correct?

A related issue concerns the instantiation of template classes. If I
understand the way that would work, a template class cannot be given the
dllexport attribute, however, one could explicitly instantiate the class and
specify the attribute.

For example:

template <class T>
class A
{
} ;

template class __declspec( dllexport ) A<char> ; // Legal, right ???

Although I am puzzled about how exactly the import would be declared in a
header file. Perhaps:

typedef A<char> mytype ;

template class __declspec( dllimport ) A<char> ;

Or is there some other way?

 

[Doug Harrison [MVP]]

While attempting to implement this suggestion, I am having difficulty
interpreting a semanic issue with respect to the __declespec(
dllexport/dllimport ) keyword. Suppose for example a class is declared in a
header file:

//Header file 'a.h' :

#ifndef API
#define API __declspec( dllimport )
#endif

class
API
a
{
void do_some_stuff( void ) const ;
} ;

// Implementation file:

#define API __declspec( dllexport )

That's not the best way to use those __declspecs; see this message for a
better way:

http://groups.google.com/[email protected]

#include "a.h"

namespace {

struct B { int n ; } ;

B _b ;

} // END:: anonymous namespace

a::do_some_stuff( void ) const
{
_b.n++ ;
}

// END implementation file.

Will the static global _b declared in the anonymous namespace be properly
initialized by the CRT when the DLL startup code runs without specifying any
specific attributes?
Yes.

If I understand the way a DLL should work, I would claim that static global
_b in the anonymous namespace would be instantiated in the DLL's private
segment when a process attaches.

Is this correct?

Yes. It will be in the DLL's data segment, and it will be initialized and
destroyed when the DLL receives the DLL_PROCESS_DETACH and
DLL_PROCESS_DETACH notifications. But see "DllMain" in MSDN for some
important restrictions which apply to DLL global data initialization, which
is performed from DllMain context. See this message for a problem which can
affect local static data in DLLs:

http://groups.google.com/[email protected]

A related issue concerns the instantiation of template classes. If I
understand the way that would work, a template class cannot be given the
dllexport attribute, however, one could explicitly instantiate the class and
specify the attribute.

For example:

template <class T>
class A
{
} ;

template class __declspec( dllexport ) A<char> ; // Legal, right ???

Although I am puzzled about how exactly the import would be declared in a
header file. Perhaps:

typedef A<char> mytype ;

template class __declspec( dllimport ) A<char> ;

Or is there some other way?

That syntax is almost right. See these articles for more:

HOWTO: Exporting STL Components Inside & Outside of a Class
http://support.microsoft.com/?kbid=168958

Explicit Instantiation
http://msdn.microsoft.com/library/d...ang/html/_pluslang_explicit_instantiation.asp

 

[Robert A Riedel]

While porting the library to a DLL, there are numerous occassions where a
C4251 compiler warning is encountered on certain class private data. Since
clients of these classes have no reason to access the private data section,
are these warnings material and do they need to be remediated?

 

[Doug Harrison [MVP]]

While porting the library to a DLL, there are numerous occassions where a
C4251 compiler warning is encountered on certain class private data. Since
clients of these classes have no reason to access the private data section,
are these warnings material and do they need to be remediated?

You should make sure that no inline function accesses the data member. This
includes default ctor, copy ctor, dtor, and assignment operator the compiler
generates for you. You should define all these members out of line. Then if
the compiler still complains about C4251, you should be able to ignore it.

See these messages for more on C4251:

http://groups.google.com/[email protected]
http://groups.google.com/[email protected]
http://groups.google.com/[email protected]

 

[Robert A Riedel]

Thanks for the info.

The other thing that it seems possible to do is to only export the public
functions and data, instead of the entire class.

 

[Doug Harrison [MVP]]

Thanks for the info.

The other thing that it seems possible to do is to only export the public
functions and data, instead of the entire class.

That can often work, but exporting/importing the whole class does something
special. See this message for more on that:

http://groups.google.com/groups?selm=01bc60c3$4fd946e0$4862389d@philiplu2