Mail Archives: cygwin/2000/08/30/10:49:18
Paul Sokolovsky wrote:
>
> Hello cygwin,
>
> Existance of several GNU targets based on incompatible underlying
> libraries brings (or will bring soon) problem of clashes between their
> components. Mere installing software build with each of them into
> separate directory and setting PATH to one of the in per-session
> manner is not flexible since often one piece of software absent in
> that or another distribution. Of particular importance here is
> clashing of DLLs which is espicially hard to detect for end users. It
> would be nice if there were some convention for naming DLLs build for
> particular target. Cygwin did that for a some time, for example,
> native builds of Tcl/Tk, etc. used to have 'cyg' prefix. However,
> latest additions seem not to follow this practise.
Yup, I know. Most the latest additions which have dll's were ones that
I ported. I did not want dependent packages to be required to modify
their makefiles to use '-lcygtiff' or worse yet, '-lcygtiff35' when a
plain '-ltiff' is already there and works. The tcl/tk stuff is a
special case, I believe, since it's a wierd half-native/half-cygwin
build...
So far, the only problems I have seen are zlib (cygwin version clashing
with Suhaib's cygwin-XFree version), and it is conceivable that windows
versions of zlib/libpng can clash with the cygwin versions of same.
However, the cygwin-zlib works with XFree, so you can just delete the
cygwin-xfree zlib.dll. I haven't seen too many reports of actual
problems with windows dlls clashing with cygwin dlls; several folks have
mentioned that 'it could happen, we should fix it before it does' but
nobody has *actually* had it happen to them.
I've no interest in fixing a problem (and causing many many more
problems) when the initial problem has not been demonstrated to affect
real users.
>
> Will it be possible to re-consider this matter and if it applies,
> recommend to follow it?
Maybe. But I won't even accept patches to do that to the packages I
maintain until the dependency problems are resolved, or folks on the
list agree that the inevitable hassles and constant FAQs: 'you need to
change -ltiff to -lcygtiff in the makefile...' are worth it.
One less intrusive possibility I have thought of is:
import lib: libtiff{ver?}.dll.a (built with
--dllname=cyglibtiff{ver?}.dll)
dll : cyglibtiff{ver?}.dll
If this is done, then you no longer can link directly to the dll
(without changing the makefile to say '-lcyglibtiff{ver}', but
ordinarily you'd link using the import lib so everything would be ok,
and you can still use '-ltiff' in the makefile.
I'm not really in favor of using version numbers on shared libs, since
you'd also have to version the import libs also and then use symlinks a
la unix....but this should be discussed on the list.
libtiff.dll.a -> libtiff{latest-ver}.dll.a
> More importantly, it can be automatically
> supported on appropriate level (in libtool).
No, it can't. Currently, libtool itself doesn't support *building*
dlls. Also, you are assuming that every package that depends on
dll-ized libraries uses libtool in its build process. While that would
be great, it is not true. Unfortunately, *very* few packages use
libtool, in my experience.
Comments, anyone?
--Chuck
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -