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 staticARGH. 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.
--Chuck
--
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/
