public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Mumit Khan <khan@nanotech.wisc.edu>
To: "vincent penne" <vincent.penne@freesbee.fr>
Cc: cygwin@sourceware.cygnus.com
Subject: Re: Building C++ library DLL
Date: Sat, 13 Nov 1999 11:44:00 -0000	[thread overview]
Message-ID: <199911131944.NAA01172@mercury.xraylith.wisc.edu> (raw)
In-Reply-To: <000701bf2d48$41067260$2e0981d4@ziggy>

"vincent penne" <vincent.penne@freesbee.fr> writes:
> 
> -----Message d'origine-----
> De : Mumit Khan <khan@nanotech.wisc.edu>
> À : vincent penne <vincent.penne@freesbee.fr>
> Cc : cygwin@sourceware.cygnus.com <cygwin@sourceware.cygnus.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@sourceware.cygnus.com

WARNING: multiple messages have this Message-ID
From: Mumit Khan <khan@nanotech.wisc.edu>
To: "vincent penne" <vincent.penne@freesbee.fr>
Cc: cygwin@sourceware.cygnus.com
Subject: Re: Building C++ library DLL
Date: Tue, 30 Nov 1999 23:39:00 -0000	[thread overview]
Message-ID: <199911131944.NAA01172@mercury.xraylith.wisc.edu> (raw)
Message-ID: <19991130233900.-_TdMVPgehwarF2X2Dj8d8YpcrLBXi1fdYrdA3PIQ6w@z> (raw)
In-Reply-To: <000701bf2d48$41067260$2e0981d4@ziggy>

"vincent penne" <vincent.penne@freesbee.fr> writes:
> 
> -----Message d'origine-----
> De : Mumit Khan <khan@nanotech.wisc.edu>
> À : vincent penne <vincent.penne@freesbee.fr>
> Cc : cygwin@sourceware.cygnus.com <cygwin@sourceware.cygnus.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@sourceware.cygnus.com

  reply	other threads:[~1999-11-13 11:44 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-11-12 11:52 vincent penne
1999-11-13 11:44 ` Mumit Khan [this message]
1999-11-30 23:39   ` Mumit Khan
1999-11-30 23:39 ` vincent penne
  -- strict thread matches above, loose matches on Subject: below --
1999-11-13 12:47 Vincent Penne
1999-11-30 23:39 ` Vincent Penne
1999-11-12 21:28 Vincent Penne
1999-11-30 23:39 ` Vincent Penne
1999-11-12 14:01 bughz
1999-11-30 23:39 ` bughz
1999-11-12 12:06 Steve Jorgensen
1999-11-30 23:39 ` Steve Jorgensen
1999-11-11 20:50 vincent penne
1999-11-12  9:12 ` Mumit Khan
1999-11-30 23:39   ` Mumit Khan
1999-11-30 23:39 ` vincent penne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199911131944.NAA01172@mercury.xraylith.wisc.edu \
    --to=khan@nanotech.wisc.edu \
    --cc=cygwin@sourceware.cygnus.com \
    --cc=vincent.penne@freesbee.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).