Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
To: DJ Delorie <dj AT delorie DOT com>
Cc: scarpe AT atos-group DOT com, cygwin AT sourceware DOT cygnus DOT com
Subject: Re: Making DLL's.
References: <1 DOT 5 DOT 4 DOT 32 DOT 19990318210722 DOT 0067d298 AT lola DOT univ-lemans DOT fr> <3564 DOT 990319 AT is DOT lg DOT ua> <36F258AB DOT CC1A1788 AT atos-group DOT com> <199903191530 DOT KAA01054 AT envy DOT delorie DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
From: gvaughan AT oranda DOT demon DOT co DOT uk (Gary V. Vaughan)
Date: 22 Mar 1999 10:31:32 +0000
In-Reply-To: DJ Delorie's message of "Fri, 19 Mar 1999 10:30:55 -0500"
Message-ID: <u1zihvmrf.fsf@oranda.demon.co.uk>
Lines: 89
User-Agent: Gnus/5.070079 (Pterodactyl Gnus v0.79) Emacs/20.3

DJ Delorie <dj AT delorie DOT com> writes:

> > Can't anyone out there make "ld -b" produce dll (or may be some .so
> > file, but may be i'm dreaming awaken) so that we can have a real
> > standard way to build shared library ?
> 
> I've already done it, it just hasn't been released with cygwin yet.
> Basically, "ld -shared *.o foo.def -o foo.dll" will work in the new
> version (or gcc -Wl,-shared ...)

First; another answer:

The upcoming libtool release, and to a marginally lesser extent, the most
recent alpha release (ftp://alpha.gnu.org/pub/gnu/libtool/libtool-1.2f.tar.gz),
make a pretty decent stab at both building dlls, and linking against them
in a cygwin environment.

Then a question:

The only fly in the ointment for libtool's dll support is handling the export
of data items from a dll.  Specifically, an object that will be linked into
an executable which will in turn be linked with a handful of libraries (some
static and some dll's, for argument's sake) needs to produce different code
depending on what particular combinations of dll and static libraries it will
ultimately be linked with.

That is I need to make sure that any data item that will be imported from a
dll has __attribute__((dllimport)), and any data item imported from a static
library cannot have this attribute.  Obviously, in a makefile driven build
environment there is no easy way to know which combination of libraries this
object will eventually be linked with... is there a way around this problem?
Or do I have to come up with some kind of makefile scanner to figure out
which attributes to attach to each symbol?

Actually, 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
        2) imported from another dll
        3) imported from a static library
        4) externed in the tradition way if it will be part of a static lib

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?

My (flawed) best solution so far is:

        /* foo.h */
        #ifdef __CYGWIN__
        #  ifdef _COMPILING_FOO_DLL_
        #    define EXTERN __declspec(dllexport)
        #  else
        #    define EXTERN extern __declspec(dllimport)
        #  endif
        #else
        #  define EXTERN extern
        #endif

        EXTERN int foo;

When building the dll, I need:

        /* foo.c */
        #define _COMPILING_FOO_DLL_
        #include "foo.h"

When linking against the dll on cygwin or otherwise:

        /* bar.c */
        #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|

What now?

Cheers,
        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 AT sourceware DOT cygnus DOT com