Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Message-Id: <199911131944.NAA01172@mercury.xraylith.wisc.edu>
To: "vincent penne" <vincent DOT penne AT freesbee DOT fr>
cc: cygwin AT sourceware DOT cygnus DOT com
Subject: Re: Building C++ library DLL 
In-Reply-To: Your message of "Fri, 12 Nov 1999 20:58:13 +0100."
             <000701bf2d48$41067260$2e0981d4 AT ziggy> 
Date: Sat, 13 Nov 1999 13:44:06 -0600
From: Mumit Khan <khan AT thor DOT xraylith DOT wisc DOT edu>

"vincent penne" <vincent DOT penne AT freesbee DOT fr> writes:
> 
> -----Message d'origine-----
> De : Mumit Khan <khan AT nanotech DOT wisc DOT edu>
> À : vincent penne <vincent DOT penne AT freesbee DOT fr>
> Cc : cygwin AT sourceware DOT cygnus DOT com <cygwin AT sourceware DOT cygnus DOT com>
> Date : vendredi 12 novembre 1999 18:12
> Objet : Re: Building C++ library DLL
> 
> 
> >
> >It should work. Why not just try it out?
> >
> >
> 
> I tryed on a simple example, and it turned out that one problem came from
> the fact that the extenstion of my objects was not .o but .dllo (it's
> because I was creating a static library at the same time).
> It seems dllwrap only works when it is given some .o objects ...
> 
> My simple example works then ...
> 
> But with a more complicate library, I still have some internal compiler
> error when using class that are defined as
> class __declspec(dllimport) foo

This is of course illegal. You cannot *define* an imported class. That's
where all those preprocessor macros come in -- you declare when importing,
define when exporting.

> 
> Here is an example of such message :
> 
> ././Fl_Menu_Type.cxx:469: Internal compiler error, output_operand_lossage
> `inval
> id expression as operand'
> 
> The line where it crashes is a declaration of a variable of type foo, it is
> not a variable of the library, but a variable of the program that uses it
> ...

There are a whole bunch of bugs and limitations of dllimport/dllexport
code when it comes to C++, and some of these are very hard to fix. One
particular one that has been reported here is especially troublesome --
when you import a class with virtual function, and derive from it in
user code, the vtable code is screwed up (since we can't just take the
address/offset of "this" pointer when the class is in the DLL).

I do hope others will jump in and try to fix this; I have very limited
free time right now, and this is going to take more than just a tweak.

> I am using gcc 2.95, but I encountered some internal errors with egcs too
> (however I'm not sure they were happening at the same points, I might try
> this now ...)

Please feel free to send me testcases. If it's over a few megabytes, please 
don't email me the whole thing -- I'll set up a temporary upload area.

I need to write up the list of known bugs. Hopefully this week sometime.

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com