delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1998/03/12/05:38:38

From: khan AT xraylith DOT wisc DOT edu (Mumit Khan)
Subject: Re: More DLL issues
12 Mar 1998 05:38:38 -0800 :
Message-ID: <Pine.LNX.3.96.980311140024.7534A-100000.cygnus.gnu-win32@eh_pc11.xraylith.wisc.edu>
References: <01bd4b86$82373940$60040d8d AT ROGKOMUN>
Mime-Version: 1.0
To: =?iso-8859-1?Q?Roger_Ren=E9_Kommer?= <roger AT isp DOT uni-kassel DOT de>
Cc: gnu-win32 AT cygnus DOT com

On Mon, 9 Mar 1998, [iso-8859-1] Roger René Kommer wrote:
> 
> [ ... ]. I think the solution like MS it does, using extensions
> __declspec(dll[ex|im]port), etc. doesn't fit to cygnus needings, because it
> does also needs modifications of sourcecode. I would prefer a standard,
> which looks like more transparent .so solution.

What .so solution are you talking about?? ELF? SunOS? The Unix shared
library design, at least for ELF, AIX, HP-UX, etc, are so different than
the MS DLL design that it might not be possible to create a "transparent"
mechanism. Hence the __declspec(dll[ex|im]port), which IMO is a reasonable
compromise given the alternatives (or the lack thereof).

> 
> (Just a note: in Qt global defined classes are exported (and used) with the
> name 'red', 'blue', 'green'. Puh!, C++ and cpp is incompatible by design and
> I understand the language designers of java that they doesn't integrate a
> cpp.)

I have no idea what the above means, so I'll leave it alone ;-)

> There is another problem with gcc:
> In sources we can often found this construction:
> /* dummy.c: */
> #include <stdio.h>
> FILE *yyin = stdin;

You meant to say "There is another problem with non-portable code ...", 
right ;-?

> To resolve this, you have to replace bclass.aclass with
> (*__imp__6BClass$aclass).
> This cannot be solved by cpp macros, but the sources must be modified. In
> most cases it helps to wrap the access to this static members in non inlined
> normal or static member functions.

The correct solution IMO is to implement the "dllimport" and "dllexport"
attributes in gcc/win32, and if I get a bit of free time, I'll implement
it in the near future (do I hear volunteers coming forward ...). I started 
with Doug Evans' work on ARM/PE and have some of it implemented, but too
incomplete and buggy to be usable right now.

If you are willing to work on this and/or need more info on this, let me 
know.

> 
> - Integrating dlltool and other tools inside gcc/ld
> 

Now, that'd be terrific. Unfortunately, someone has yet to come forward to
do the work.

Mumit

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019