Hello, Guido. I have some comments interleaved...
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > Guido Draheim > Sent: Friday, December 21, 2001 12:51 AM > To: Jon Leichter > Cc: [EMAIL PROTECTED] > 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 _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
