This is the mail archive of the
mailing list for the Cygwin project.
Re: [avail for test] libtool-devel-20030121-1
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- To: Ralf Habacker <Ralf dot Habacker at freenet dot de>
- Cc: cygwin at cygwin dot com
- Date: Tue, 11 Feb 2003 00:43:52 -0500
- Subject: Re: [avail for test] libtool-devel-20030121-1
- References: <000001c2d13b$d5c30a40$5c1306d5@BRAMSCHE>
Ralf Habacker wrote:
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.
May be, but like Max has stated, I don't like to be forced to make every static
ARGH. This defeats the whole purpose of the policy change -- and it is
a policy change driven by the libtool development. I don't want to
support a forked version of libtool that differs from mainline on a
basic policy issue.
lib as shared lib. This would break the whole kde build system, because often
convenience librarys are build and assembled together into a dll.
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.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html