This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project. See the Cygwin home page for more information.
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index] [Subject Index] [Author Index] [Thread Index]

Re: Making DLL's.



Thanks for the response.

Fergus Henderson <fjh@cs.mu.OZ.AU> writes:

> On 22-Mar-1999, Gary V. Vaughan <gvaughan@oranda.demon.co.uk> wrote:
> > [[snip]] libtool compounds the problem, because it wants to produce both
> > static and dll libraries for each library object, and thus a given data
> > symbol may be:
> >         1) exported from this object if the object will be part of a dll
> >         4) externed in the tradition way if it will be part of a static lib
> 
> The difference between 1) and 4) is already important on many Unix
> systems, where you need to compile with `-fpic' in case 1),
> but you don't need any special options in case 4).
> So your Makefile ought to already be set up to handle this.
> On Windows, just replace `-fpic' with `-DCOMPILING_FOO_DLL'
> and then use the #ifdefs you mentioned.

Hmmm... well, we already pass -DPIC alongside -fpic, so it may be that
I can simply check for this cpp symbol when compiling the objects for a
dll that has no dependencies.  Now that you have mentioned this, it occurs
to me that since we already take pains not to make a shared library dependant
upon a static archive (is that a legal thing to do with win32? it certainly
fails on many unices), I can intuit that I need to __declspec(dllimport)
any data items which are imported from other libraries which this one
depends on, if PIC is defined (and I am thus building an object for a dll).

> (N.B. You should really use `COMPILING_FOO_DLL' rather than
> `_COMPILING_FOO_DLL_', because according to ISO C and C++,
> the latter is reserved for use by the implementation.)

Good point.  Thanks.

> >         2) imported from another dll
> >         3) imported from a static library
> 
> This distinction is not present in Unix, and yes, it is
> a real pain.  I have avoided it by either always using
> a static library or always using a DLL for any given 
> library.

Yes, that is what we do currently, forcing everything to be statically linked,
and although it works adequately, I would *really* like to offer the same
shared library facilities (within the limits of win32 dlls) that unix has.

> > So, my question is:  do I really have to figure out whether this object is
> > destined to become part of a static library, a dll, or an executable, and
> > which libraries that destination will depend on and whether each of them
> > will be a dll or not in order to produce the correct code for each
> > exported data symbol?
> 
> Basically yes.  And it is a real pain.

I had feared as much.  *sigh*

> But it's not _quite_ as bad as you make out.
> [[snip]]
> 
>          /* foo.h */
>          #if defined(__CYGWIN__) && defined(DEFINE_FOO_DLL)
>          #  define FOO_EXTERN __declspec(dllexport)
>          #elif defined(__CYGWIN__) && defined(USE_FOO_DLL)
>          #  define FOO_EXTERN extern __declspec(dllimport)
>          #else
>          #  define FOO_EXTERN extern
>          #endif
>  
>          FOO_EXTERN int foo;
> 
> (I prefer the name DEFINE_FOO_DLL rather than COMPILING_FOO_DLL.)
> 
> Note that if you're using C rather than C++, then it is in fact
> possible to simplify this a little, so that you don't need to add all
> those FOO_EXTERN symbols to all the declarations in the header files. 
> See <http://www.cs.mu.oz.au/~fjh/gnu-win32/how-to-build-dlls.html> for
> details.  Note that the stuff there is fairly old; it dates back to
> version b18 or thereabouts.  I haven't tested it with more recent versions.

This looks as though it may be exactly what I was looking for, in that I
would really like to be able to take virgin unix sources which already use
libtool (which is what I am working in), and have them automatically do
the right thing with respect to creating a dll on win32 where a shared lib
would have been created in an equivalent build on unix.

In time, that will hopefully mean that as libtool gets wider usage in
the GNU community, projects which use libtool will automatically have
a cygwin port in most cases.

> > When building the dll, I need:
> > 
> >         /* foo.c */
> >         #define _COMPILING_FOO_DLL_
> >         #include "foo.h"
> ...
> > Which works fine, until I try to build an equivalent static libfoo.a from
> > the foo sources on cygwin, when ofcourse I get `undefined __imp_foo'
> > errors =(O| 
> 
> It's better to pass -D_COMPILING_FOO_DLL_ or -DDEFINE_FOO_DLL
> on the command line via make, rather than hard-coding it
> in your source file.  That way you can avoid passing it when you
> build your static libraries.

Thanks, this was of great help to me.

        Gary.
-- 
  ___              _   ___   __              _             
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___ 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
PGP Key from/___/                      /___/               
http://www.cl.cam.ac.uk/PGP/pks-commands.html#extract      
http://pgp.ai.mit.edu/~bal/pks-commands.html#extract       


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com