Mail Archives: cygwin/2001/03/27/23:41:44
Static constant initialisation of data in C++ classes works when linking
statically, but not with dllimported classes. This is a bug with older
versions of gcc as well as gcc-2.95.3.
The following code used to build dll:
dllclass.h
======================================
#if BUILDING_DLL
# define DLLIMPORT __declspec (dllexport)
#else /* Not BUILDING_DLL */
# define DLLIMPORT __declspec (dllimport)
#endif /* Not BUILDING_DLL */
class DLLIMPORT
DllClass {
public:
DllClass();
unsigned int a_method () const;
static int non_const_int; /* initialised in dllclass.cc */
static const unsigned int const_int=256;
char buffer[const_int];
};
==========================================
dllclass.cc
===========================================
#include "dllclass.h"
#include <string.h>
DllClass::DllClass(){
memset(buffer,0,const_int);
}
unsigned int
DllClass::a_method () const {
return const_int;
}
int
DllClass::non_const_int;
============================================
Dll build correctly.
non_const_int is exported as DATA.
const_int is not exported. That's fine.
This is client code:
usedll.cc
=========================================
#include <stdio.h>
#include "dllclass.h"
int main () {
DllClass A;
printf("a_method = %d\n", A.a_method());
}
==========================================
This fails to compile with error:
dllclass.h:13: initialized variable `const int DllClass::const_int' is marked
dllimport
In this case, (integral const), one workaround is the enum hack.
- static const unsigned int const_int=256;
+ enum {const_int=256};
The problem occurs because class members get the dllimport/export status
of their class.
IMO static const data members of classes initialised in class definition should
not "inherit" the dllimport attribute of their class.
The following w32-specific patch to gcc/config/i386/winnt.c fixes the problem.
I have tested with STLport, which uses static const initialisation of
fmtflags (in ios_base) and locale categories, and no problems yet.
However, I am very, very new to the insides of gcc and this patch
probably breaks soemthing else. Can somebody who "knows what they are
doing" check.
--- gcc/config/i386/winnt.c.orig Wed Jan 19 19:30:10 2000
+++ gcc/config/i386/winnt.c Tue Mar 27 22:03:47 2001
@@ -250,6 +250,11 @@ i386_pe_dllimport_p (decl)
context = associated_type (decl);
if (context)
{
+ /* Don't use context to mark initialised variables as dllimport */
+ if (TREE_CODE (decl) == VAR_DECL
+ && (DECL_INITIAL (decl)
+ && ! TYPE_NEEDS_CONSTRUCTING (TREE_TYPE (decl))))
+ return 0;
imp = lookup_attribute ("dllimport",
TYPE_ATTRIBUTES (context));
if (imp)
Danny
_____________________________________________________________________________
http://my.yahoo.com.au - My Yahoo!
- Have news, stocks, weather, sports and more in one place.
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -