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: <17B78BDF120BD411B70100500422FC6309E0B9@IIS000>
From: Bernard Dautrevaux <Dautrevaux AT microprocess DOT com>
To: "'Charles Wilson'" <cwilson AT ece DOT gatech DOT edu>,
        Paul Sokolovsky
	 <paul-ml AT is DOT lg DOT ua>
Cc: cygwin AT sources DOT redhat DOT com
Subject: RE: DLL naming conventions
Date: Wed, 30 Aug 2000 18:36:19 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

> -----Original Message-----
> From: Charles Wilson [mailto:cwilson AT ece DOT gatech DOT edu]
> Sent: Wednesday, August 30, 2000 4:52 PM
> To: Paul Sokolovsky
> Cc: cygwin AT sources DOT redhat DOT com
> Subject: Re: DLL naming conventions
> 
> 
> 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...

I agree 100%; I port a lot of software to Windows and would *hate* having to
change -ltiff to -lcytiff everywhere :-) 

However having problems because I need some version of the DLL coming from
some provider (e.g. the cygwin-compatible tcl DLL) and picking another one
just because they both are named tcl.dll is just a nuisance. All my DLLs are
usually named as <vendor><lib-name><version>.dll with import libraries named
just lib<lib-name>.a (as you propose also below).


	<skipped>

> > 
> >   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 usually do just that with my own DLLs :-) Note that I NEVER put version
numbers on the import libraries and ALWAYS put them on dll themselves, so
that I can have tools using several versions of the DLL installed at once
without any problem (as long as my DLLs do not share data between instances
like cygwin itself where this will clearly broke apart).

> I'm not really in favor of using version numbers on shared 
> libs, 

I always do this, for reasons explained below :-)

> 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

Why? usually the compile environment is quite well controlled so that the
header files, import libraries and DLLs are all in sync, so there is no need
to version the import library; however it is interesting to version the DLL
itself to avoid having to recompile everything (even obsoleted stuff) each
time a new version fo the DLL gets out.

Note that I'm biased at writing supported code, where I want to avoid as far
as possible the risk of some code working in my environment because I pick
version X.Y of some DLL and failing at the customer site, perhaps at the
other end of the world (actually not yet really, just at the other end of
France, but we can dream :-)) because he picks version X.Y+1 from the
evaluation of some new stuff I do not have installed yet on the support
people machine :-(

However I'm supporting strongly the ability of having old and new versions
of tools working together on the same machine; for a long time I avoided
DLLs just for that but with versioned DLLs I can use them and my execs are a
lot lighter :-)

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

I think libtool is quite irrelevant here; even manually we can do all that
without too much of a hassle, as long as we have sorted out the clumsy
windows-dll building mechanism, but due to the discussion I take that for
granted :-).

Regards,

		Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux AT microprocess DOT com
		b DOT dautrevaux AT usa DOT net
-------------------------------------------- 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com