Subject: Re: More DLL issues
From: [email-masked] (Mumit Khan)

12 Mar 1998 05:38:38 -0800
Message-ID: <[email-masked]>
References: <01bd4b86$82373940$60040d8d@ROGKOMUN>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: 8bit
To: =?iso-8859-1?Q?Roger_Ren=E9_Kommer?= <[email-masked]>
Cc: [email-masked]

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
"[email-masked]" with one line of text: "help".