[avail for test] libtool-devel-20030121-1

[Ralf Habacker]

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

Regards
Ralf


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/