Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <39AF0D40.6A0942DB@ece.gatech.edu>
Date: Thu, 31 Aug 2000 21:58:24 -0400
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Gary V. Vaughan" <gvv AT techie DOT com>
CC: Paul Sokolovsky <paul-ml AT is DOT lg DOT ua>, cygwin AT sources DOT redhat DOT com
Subject: Re: DLL naming conventions
References: <19558 DOT 000830 AT is DOT lg DOT ua> <39AD1F78 DOT 4F5EAABE AT ece DOT gatech DOT edu> <20000831230822 DOT R7695 AT demon DOT co DOT uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Gary V. Vaughan" wrote:
> 
> On Wed, Aug 30, 2000 at 10:51:36AM -0400, Charles Wilson wrote:
> > No, it can't.  Currently, libtool itself doesn't support *building*
> > dlls.
> 
> Ouch.  Yes it does.  I added support around Christmas 1998, and have
> been maintaining it ever since.

Thanks for the correction.

> 
> Yes it does.  And provided your libraries don't trip over the stupid
> dll limitation of "to export a non-function symbol you must edit your
> sources", it works easily.  Even if you do export data symbols,
> libtool woll build and link against a dll for you (even generating an
> import lib along the way).
> 
> Unfortunately libtool was developed for Unix and assumes a featureful
> shared library architecture, which doesn't map very easily onto win32
> dll's.
> 
> I will be able to simplify the dll build process a little when DJ's
> patches to binutils arrive in a cygwin release (did this happen in
> 1.1? I have been so busy with m4 that I only upgraded from b20.1 a few
> weeks ago).

They landed in binutils-20000625, and were finetuned/tweaked to a fairly
stable point by binutils-20000722 (the current version in /latest).

Also, there were a few additions that changed ld's default search order
for libraries:
  -Bstatic -lfoo  : 
    looks for libfoo.a
  -Bdynamic -lfoo : 
    looks for libfoo.dll.a (default name for an import lib)
         then foo.dll.a    (alt. name for an import lib)
         then libfoo.dll   (link directly to a dll)
         then foo.dll      (ditto, alt. name)
     finally, libfoo.a     (fall back to static lib)

The spec file for gcc (as of 2.95.2-2) changed so that:
   gcc -static   calls 'ld -Bstatic'
   gcc           calls 'ld -Bdynamic'

Finally, 'gcc -shared' will build a dll, but you need to pass linker
options like '-Wl,--out-implib=libfoo.dll.a' explicitly. 

FWIW, all of the (non-libtool) libraries I've dll-ized do not use
dlltool at all, and rely only on gcc (and ld, indirectly).

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com