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:30:48 +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: <955545998.20040101113048@familiehaase.de>
To: cygwin AT cygwin DOT com
CC: Yaakov S <yselkowitz AT netscape DOT net>
Subject: Re: Building DLLs from libs
In-Reply-To: <36375665.20040101111421@familiehaase.de>
References: <bt0nhu$6de$1 AT sea DOT gmane DOT org> <36375665 DOT 20040101111421 AT familiehaase DOT de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

Hallo Gerrit,

replying myself....


Am Donnerstag, 1. Januar 2004 um 11:14 schriebst du:

> 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

I didn't mention one important part.

Add the -no-undefined flag to the libxyz_la_LDFLAGS before running
autoreconf, like in this case for libidn:

$ cat libidn-0.3.5-1.patch
--- libidn-0.3.5/lib/Makefile.am~       2004-01-01 11:19:20.657687500 +0100
+++ libidn-0.3.5/lib/Makefile.am        2004-01-01 11:19:20.657687500 +0100
@@ -34,7 +34,7 @@
        punycode.h punycode.c \
        idna.h idna.c
 libidn_la_LIBADD = $(LTLIBICONV)
-libidn_la_LDFLAGS = -version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE)
+libidn_la_LDFLAGS = -no-undefined -version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE)
 
 nfkc.c: gunibreak.h gunicomp.h gunidecomp.h
 


> 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/