This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Building DLLs from libs

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:

>> 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 (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 like the following.  Remove lines like these:
> AC_PREREQ(2.12)
> from

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/       2004-01-01 11:19:20.657687500 +0100
+++ libidn-0.3.5/lib/        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:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]