libtool
[Top][All Lists]
Advanced

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

RE: DLL_EXPORT and MinGW/Cygwin


From: Jon Leichter
Subject: RE: DLL_EXPORT and MinGW/Cygwin
Date: Thu, 27 Dec 2001 18:08:19 -0800

> -----Original Message-----
> From: address@hidden [mailto:address@hidden Behalf Of Guido Draheim
> Sent: Thursday, December 27, 2001 7:38 AM
> To: Jon Leichter
> Cc: address@hidden; address@hidden
> Subject: Re: DLL_EXPORT and MinGW/Cygwin
>
> 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.
> >

I do consider it a problem when the libtool script that gets built for my
environment (MinGW/Cygwin) includes -DDLL_EXPORT when shared objects are
built. I do not think this macro should be defined unconditionally. Perhaps
libtool needs to include a switch on the command line to allow one to
specify additional PIC flags, e.g. --pic="-DLIBfoo_DLL_EXPORT".

Jon




reply via email to

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