libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: improve support for building DLLs on cygwin and mingw


From: Danny Smith
Subject: RE: improve support for building DLLs on cygwin and mingw
Date: Fri, 08 Sep 2006 10:08:40 +1200

> 
> I propose to make 'dllexport' unnecessary, and to make it 
> possible to use 'dllimport' everywhere where the users were 
> used to write either 'dllimport' or 'dllexport', depending on 
> the compilation pass and unit. 


I think what bothers me most is that this will encourage people to use
your Method 4 as a "easier" alternative to Method 3. Method 3 is
documented by MS as the method to use on windows32 targets. It is
portable amongst native compilers. Method 4 is not.

Additionally, there are still compiler problems with the import/export
semantics
of C++ classes.

class __declspec(dllexport) foo
{
 virtual int virtual_method()
};

tells the compilier that this is the implentation of the class,
so emit the vtable, static data members, function definitions 
and typeinfo objects. 

class __declspec(dllimport) bar
{
 virtual int virtual_method()
};

tells the compliler that this is just the interface to an externally
defined class, so don't emit the static data menbers,  vtable .

class /* no declspecs */ hoo
{
 virtual int virtual_method()
}

says that this is a hidden class in terms of dll exports -- ie, private
to  dll use.  
(Putting a dlleport on it is just the windows way of adding a visibility
attribute
to override the default).  Since it is private, we can just follow the
usual heuristics
for emitting vtables,etc.

I think for Method 4 to work, the semantics will have to change and we
will need
to always emit the vtables. In addition to causing bloat, this approach
can
(has in past, still does) cause problems in  multiple inheritance cases.

Finally, I would like to see some testcases that force exception
unwinding info to be tracke
though the "self-reference" (will it work with a table-based -- ie, DW2
-- EH model? )
 
I guess what I'm saying is that this Method 4 should not be promoted as
portable
way of doing things.

I think that having GCC warn that it is ignoring a user-specified
attribute is a good thing.. 

And that's all I've go to say about that.

Danny





reply via email to

[Prev in Thread] Current Thread [Next in Thread]