From: khan AT xraylith DOT wisc DOT edu (Mumit Khan) Subject: Re: More DLL issues 12 Mar 1998 05:38:38 -0800 Message-ID: References: <01bd4b86$82373940$60040d8d AT 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?= 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 > 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".