Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-ID: <17B78BDF120BD411B70100500422FC6309E0B9@IIS000> From: Bernard Dautrevaux To: "'Charles Wilson'" , Paul Sokolovsky 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 X-Mailer: Internet Mail Service (5.5.2650.21) 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 .dll with import libraries named just lib.a (as you propose also below). > > > > 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