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

[Charles Wilson]

Ralf Habacker wrote:
>>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.
>>
> 
> May be, but like Max has stated, I don't like to be forced to make every static
> lib as shared lib. This would break the whole kde build system, because often
> convenience librarys are build and assembled together into a dll. 

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.

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