This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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 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, the dependencies of each created sharedlib).

But don't worry about convenience libs; those are fine.


Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]