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