RE: DLL_EXPORT and MinGW/Cygwin

[Jon Leichter]

Hello, Guido.

I have some comments interleaved...

> -----Original Message-----
> From: address@hidden [mailto:address@hidden Behalf Of
> Guido Draheim
> Sent: Friday, December 21, 2001 12:51 AM
> To: Jon Leichter
> Cc: address@hidden
> Subject: Re: DLL_EXPORT and MinGW/Cygwin
>
> Es schrieb Jon Leichter:
> >         #ifdef DLL_EXPORT
> >         #       define EXTERN extern __declspec(dllexport)
> >         #else
> >         #       define EXTERN extern
> >         #endif
>
> I am sure everyone who had been compiling a dll had seen this
> and they have been hit by the declspec-problems that you
> 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?

> 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.

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.

> And yes, I had been
> seeing the DLL_EXPORT declaration to be nothing more than a
> hint that we are going to build a dll - and IIRC a dll does
> not necessarily have to be PIC. So, it would in fact carry an
> extra information during sourcecode scanning - with possible
> #ifdefs around symbols that are only valid for a real dll-target.

Just a by-the-way: Windows object code is compiled the same whether or not
it's in an executable or a DLL. Windows does not know the true concept
associated with PIC. DLLs are assigned base start addresses. If two or more
applications access the same DLL at the same base start address, that's
great: the DLL is shared text. However, if one application is unable to use
that base start address (because some other object code already occupies
that space), the DLL will be relocated to another address, and the OS will
effectively have the same object code (i.e the DLL) loaded in two different
areas of physical memory. Brillant OS, isn't it?

By the way, I have seen that if you forget to compile shared objects in
Solaris with PIC, it will do the same thing as Windows, i.e. load the same
text into 2 different areas of physical memory.

> 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?

> /zzap/
> as a side note: I made some good success with having a define called
> *lib*_SOURCE at the top of the source files used to build *lib*. A
> header file is then free to check for this define as with:
>          #ifdef LiB_SOURCE
>          #       define LiB_EXTERN extern __declspec(dllexport)
>          #else
>          #       define LiB_EXTERN extern
>          #endif
> but others had problems with it as they wanted to link the source
> code directly into another package and the dllexport did hurt them.
> (example is http://zziplib.sf.net), and one can partially help it
> since this combined-compile happens only in non-dll-target builds
> for win32 - it is not much use to combine some dll-capable code into
> another dll that shall be shipped anyway.

As I said in my original email, I don't really ever use
__declspec(dllexport) for exactly the same reason that you stated earlier:
libtool can handle exports when it links. For that reason, I only worry
about __declspec(dllimport). My preprocessing usually looks like this:

        #if defined(_WIN32) && !defined(LiB_SOURCE) && !defined(LiB_STATIC)
        #       define LiB_EXTERN extern __declspec(dllimport)
        #else
        #       define Lib_EXTERN extern
        #endif

A header of this type should not cause any problems.

> A check for DLL_EXPORT can help here....

How so?

Jon