Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Thu, 1 Jan 2004 11:14:21 +0100
From: "Gerrit P. Haase" <gp AT familiehaase DOT de>
Reply-To: "Gerrit @ cygwin" <cygwin AT cygwin DOT com>
Organization: Esse keine toten Tiere
Message-ID: <36375665.20040101111421@familiehaase.de>
To: Yaakov S <yselkowitz AT netscape DOT net>
CC: cygwin AT cygwin DOT com
Subject: Re: Building DLLs from libs
In-Reply-To: <bt0nhu$6de$1@sea.gmane.org>
References: <bt0nhu$6de$1 AT sea DOT gmane DOT org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

Hallo Yaakov,

Am Donnerstag, 1. Januar 2004 um 09:59 schriebst du:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> OK, I googled for this one but I didn't find a clear answer, so forgive
> me if this is already "known" to the list.

> I'm trying now to package some programs which include libs and includes.
>   The preferred way AFAIK is to make three packages, foo with 
> executables and docs, libfooABI with just the DLL, and libfoo-devel with
> libs and includes.  The problem is, make doesn't build the dll by default.

That depends on the package.  E.g. we have Berkeley DB, here it is
useful to split because you may want to use older versions of the
runtime because some other executables are linked against it and you
may want to use the latest version to build new packages.

Other packages with a stable interface don't need this yet (expat,
zlib, ...).

> - From my googling it appears that there are two ways to make the DLL,
> through a mkdll.sh (which some apparently opposed) or through

It is not recommended to do this if autotools are used.  However it is
used in some packages which are part of the distribution (exercise to
the reader: which packages use this method to create DLLs?)

> re-libtoolizing.  Which is preferred and *exactly* how would I go about
> doing this?  Thanks in advance!

If the autotools are used this is the recommended way.

Which package are you trying to build?

Generally I do s.th. like the following.  Remove lines like these:
AC_PREREQ(2.12)
from configure.in

Then try this command in the top source directory:
$ autoreconf --install --verbose --force

But there are some packages where this won't work, e.g. Bruno Haible's
packages or developers who don't use all of the autotools like expat
(where automake isn't used) are usually difficult to relibtoolize.

Sometimes autoreconf is not able to do the job, then relibtoolizing
manually may help:
Optional: $ autoupdate
$ aclocal (-I /possible/include/paths)
$ libtoolize --copy --force
$ aclocal (-I /possible/include/paths)
Maybe: $ autoheader
$ automake --add-missing --force
$ autoconf

Sometimes even this doesn't work because some 'features' in older
versions of the autotools are used and these 'features' are disabled
now, sometimes 'features' are used which aren't supported by the
autotools at all (e.g expat uses non recursive make with only one
toplevel Makefile).

If you run into some specific problems, please feel free to ask the ML
about it.


Gerrit
-- 
=^..^=



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/