Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
From: "Kevin Wright" <kevin AT wright DOT org>
To: "Cygwin-Mailing-List" <cygwin AT cygwin DOT com>
Subject: FW: using libtool to create dll's with cygwin
Date: Sat, 10 Feb 2001 00:14:20 -0700
Message-ID: <000001c09331$1695cad0$2b58a940@holstein-mobile.ASPECTDV.COM>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal

-----Original Message-----
From: Gary V. Vaughan [mailto:gary AT oranda DOT demon DOT co DOT uk] On Behalf Of Gary
V. Vaughan
Sent: Thursday, February 08, 2001 1:03 PM
To: Kevin Wright
Cc: libtool AT gnu DOT org; cygwin AT redhat DOT com
Subject: Re: using libtool to create dll's with cygwin


On Wed, Feb 07, 2001 at 03:15:29PM -0700, Kevin Wright wrote:
> Gary,
>
> First, I want to thank you for your excellent book on GNU autotools.
> I'm learning a great deal from it.

Thanks.  I pleased that you like it -- but I can't take all the
credit, Ben, Tom and Ian wrote almost half of the pages in it.  I am
Cc:ing a couple of the lists that will probably be interested in the
rest of this conversation.  I hope you don't mind.

> The question I have is: you mention in the book (p. 320) that DJ Delorie
> is working on gcc go link DLLs in a single pass...
>
> I believe he is done because you can use gcc -shared to create a DLL:
>
> OBJS=foo
> BASE=foo
>
>   gcc -shared -o lib$(BASE).dll -Wl,--out-implib=lib$(BASE).dll.a \
>     -Wl,--export-all -Wl,--enable-auto-image-base  \
>     -Wl,--output-def=lib$(BASE)_.def $(OBJS)

It is even easier than that (from memory):

    gcc -shared -o cyg${BASE}.dll -Wl,--out-implib=lib${BASE}.dll.a $(OBJS)

> so, have you been able to keep up with the latest cygwin releases
> (1.1.8) and are you aware of the progress made with gcc?

Indeed.  DJ finished the work long before the book went to press, but
it took a while for his modifications to filter through to the
standard gcc binaries shipped with cygwin.  The import library
generator in libtool is based off his code in fact.

> I'm trying to build shared libraries with cygwin using libtool but I
> doesn't quite seem to be automatic. (I'm using the latest cvs sources
> of libtool, automake, autoconf, etc.)

DLL support is slightly broken at the moment in CVS libtool.  I
will add an item to my TODO list on
http://savannah.gnu.org/projects/libtool,
to make sure that I schedule fixing that before releasing libtool 1.4.
What I really want to do is set up a macro that tests for the one pass
linkage feature, and uses that in preference to libtool's current
(hairy, but portable) scheme.  There is an interesting (and very long)
debate in the cygwin archives involving Paul Sokolovsky, Chuck Wilson,
myself and others regarding how libtool should integrate with cygwin.

> I'm currently able to create DLL's manually but struggle a bit with
> how to change the headers to use __declspec(dllimport) and
> __declspec(dllexport).

The declspec thing is an absolute nightmare.  Microsoft have tried
extremely hard to make it impossible to build a dll and a static lib
from the same sources.  The only way around it is the hideous dance of
the #ifdefs.  The scheme I described in the book is very baroque, but
has worked for me with the `sic' project in the goat book, my
snprintfv library and several CVS versions of GNU m4 (probably not the
current head), along with dynamic runtime loading of modules in all of
these cases.

> I'd like to be able to use libtool to create the DLL's with just a bit of
> manual modification to the headers for the dllimport & dllexport stuff.

I can (and will) definitely do that -- with the caveat that
interlibrary dependencies are hopelessy under-featured on Windows.  I
have found that it is often necessary to move functions around so that
there are no unsatisfied symbols in the dll itself.

What I would really like is to have autoconf projects ``just work'' (tm),
but the DLL and ELF shared library architectures  are way too
different for that to happen without a new runtime loader.  That is an
enormous undertaking, and I fear that the chances of it happening are
vanishingly small.  With the next release of libtool, it will be
possible to get pretty close by specifying -no-undefined to libtool,
and a bit of #ifdef black-magic in the header files.  The difficult
part will be persuading upstream developers to work this way; or
accept patches into the upstream sources to `fix' building of dlls.

> TIA,
>
> --Kevin Wright
>
> Sunnyvale, California

Cheers,
	Gary.
--
  ___              _   ___   __              _         mailto:
gvv AT techie DOT com
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___
gary AT gnu DOT org
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public
key:
http://www.oranda.demon.co.uk
http://www.oranda.demon.co.uk/key.asc


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple