[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DLL_EXPORT and MinGW/Cygwin

From: Guido Draheim
Subject: Re: DLL_EXPORT and MinGW/Cygwin
Date: Thu, 27 Dec 2001 16:38:08 +0100

Es schrieb Jon Leichter:
> > describe - using just a DLL_EXPORT or EXTERN in an installable
> > header file is simply wrong.
> Agreed. Is someone going to "fix" this in libtool?

well, it's not particularly a libtool problem that people tend
to put a dependency of their code.... I would more or less call
it a problem of documentation and useful examples. That's what
my idea about a "dllmaker guide" circulates all around, and 
that's where I can put a big red box in there saying "don't do it"...

> > It would however help to just
> > leave it  away since the gcc/libtool compiler toolchain can
> > handle the imports/exports during the link-stage instead of
> > having it declared during compile-stage. (other compiler
> > toolchains can not do so however, well...).
> Your usage of the word "however" above initially threw me off in what you
> were trying to say. Are you once again stating that it would be better for
> DLL_EXPORT to be removed? If so, I of course agree.

not quite - I do say that DLL_EXPORT could be removed but *only* for
the case of gcc/libtool - which might make some code writer betters
since they might omit the dependency on this define... (see above).

However (*grin*) libtool is not a gcc-specific program, it can handle a
lot more sorts of compilers and linkers, and some of these might just
NEED the declspec(...) for the symbols which gcc/binutils do not not
need. This gives the counter-argument in favour of DLL_EXPORT so that
the developers using the gcc/binutils can check their sources for
correctness - well, atleast partial correctness since gcc/binutils
do not need the dllexport/dllimport stuff during compilation.

> By the way, libtool CANNOT handle imports at the link-stage. Imports must be
> dealt with at the compilation stage. Imported functions do not HAVE to be
> declared because the linker will insert stubs if necessary. However,
> imported variables MUST be declared and recognized at compile time, or else
> the object code will NOT have the correct address of the imported variable
> at run-time.

exactly! which is why I do recommend to try to avoid to export variables
from a dll since it would make a dependency on an explicit stub which we can
leave out when just handling function which, as you say, can have their stubs
generated on the fly.

> > However, I did never do this myself - in general I took the path
> > to wrap data-symbols into a function-wrapper, and then used this
> > function-wrapper for all _WIN32 target variants, not only for a dll.
> > [does this argument have some meaning? I dunno, 'm'no win pro...]
> I don't understand what you mean by this. Can you provide me with an
> example?

/* in the header file */

#ifndef _WIN32
int myvar;
#define myvar (*myvar_wrap())
extern int* myvar_wrap();

/* in the source file */

#ifndef _WIN32
int myvar
int* myvar_wrap ()
   static int _myvar;
   return &_myvar;

/* all the above quoted from memory, might not be error free... */

>> A check for DLL_EXPORT can help here....
>How so?

I am not sure, I did avoid to make a dependeny on this symbol - perhaps
the old problem about variable-exports is a case for it - IIRC, possible
targets for DLL-creation is not only _WIN32 but also a few other systems
including OS/2. All these need a wrapper around a data-symbol while PIC
systems do not need it. So... let's make an independent flag that tells
the sources to place extra code around their variables. Hmm, does that
make any sense? I am not sure....

-- guido                          
GCS/E/S/P C++$++++ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]