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

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

/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. A check for DLL_EXPORT
can help here....

cheers,
-- guido                                    http://freespace.sf.net/guidod
GCS/E/S/P C++$++++ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode)

_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Reply via email to