This is the mail archive of the
mailing list for the Cygwin project.
Re: [avail for test] libtool-devel-20030121-1
- From: "Ralf Habacker" <Ralf dot Habacker at freenet dot de>
- To: "cygwin" <cygwin at cygwin dot com>
- Cc: "Charles Wilson" <cwilson at ece dot gatech dot edu>
- Date: Sun, 16 Feb 2003 15:11:17 +0100
- Subject: Re: [avail for test] libtool-devel-20030121-1
>convenience libs do not count. You can still link a DLL with convenience libs,
because it is assumed that a true convenience lib is built by your project, for
your project, and only for your project -- it is not available to "outside
users" and therefore there can never be any mismatch between the symbols
provided by (part of) the DLL and those provided by the "real" static library.
>The prohibition is on OUTSIDE static dependencies. For instance, suppose you
only have libz.a. Now, you >build cygkde.dll (or libkde.so on some unixoid
platform) which depends on libz.a. Now, if I build chuckclient.exe which depends
on the kde shared lib, and on -lz, I could possibly get a symbol conflict.
>[This is actually more of an issue if I were trying to build chucklib.dll]
> So, the libtool folks prohibited this behavior (for this reason, and also
because it plays havoc with libtool's attempt to keep track of, via libfoo.la,
the dependencies of each created sharedlib).
> But don't worry about convenience libs; those are fine.
Thanks for this hints.
After some analyse afterwards I recognized, that the original kde libtool stuff
contains a bug in building convenience libraries. It does not include any object
files in special cases of using libtool flags, which let me go on a wrong way.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html