Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Message-ID: <39AD1F78.4F5EAABE@ece.gatech.edu>
Date: Wed, 30 Aug 2000 10:51:36 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
MIME-Version: 1.0
To: Paul Sokolovsky <paul-ml AT is DOT lg DOT ua>
CC: cygwin AT sources DOT redhat DOT com
Subject: Re: DLL naming conventions
References: <19558 DOT 000830 AT is DOT lg DOT ua>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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