DLL naming conventions

[Bernard Dautrevaux]

> -----Original Message-----
> From: Charles Wilson [ mailto:cwilson@ece.gatech.edu ]
> Sent: Wednesday, August 30, 2000 9:16 PM
> To: Bernard Dautrevaux
> Cc: Paul Sokolovsky; cygwin@sources.redhat.com
> Subject: Re: DLL naming conventions
> 
> 
> <<warning. this message is controversial. please read the entire thing
> before responding...>>

I read it all, and I have to confess one thing: I took for granted that when
talking of versioning DLLs we were talking of the "interface" version, that
is compatibility versioning. 

This mistake was aggravated by the fact that we use 4-figures version
numbers, where the first number is the product generation -- total
incompatibility even at the user level --, the second correspond to
incompatible interface changes -- but source code compatibility --, the
third one 
is changed when compatible infercae changes are done and the last one is for
bugfix releases. 

So when saying having both X.Y and X.Z it was incompatible libraries (though
you can just recompile without any source code change), not minor
versionning. 

So I agree with you, we need libpng.dll and libpng2.dll (even if I would
call the earlier one libpng1.dll for consistency, but that's a non-problem),
but having libz123a.dll would be  *huge* nuisance.
 
Note that I need to use 2 figures for the incompatible changes of my
packages as I write a lot of things in C++ and object compatibility is
sometimes more difficult to achieve than source compatibility ;-(, so I use
one figure for the source-level incompatible changes, 1 for the
source-level-compatible but nevertheless object-level incompatible changes
and two others for compatible interface change and bug fixes without any
interface change (I was going to write "without semantics change" but indeed
correcting a bug change the semantics :-)).
> 
> Bernard Dautrevaux wrote:
> > 
> > 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).
> 
> I knew I wasn't the first to think of this...
> 
> > 
> > > 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
> > 
> > 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 :-)
> 
> To me, there are two benefits to dlls:
>  
> 1) less duplicated code to store & download (compared to 
> static linking)
> 2) update a dll to incorporate bugfix -> instant update of all linked
> applications
> 
> If you version dll's, you lose #2 completely.  Disk space is cheap and
> connection speed is getting faster all the time, so #1 is kinda
> pointless these days IMO and will become more pointless in the future.
> 
> > 
> > > 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.
> 
> I think versioning import libs is just silly -- but I threw 
> it out there
> to see if it would stick.

OK :-)

> 
> Why would you have to recompile an app if a new (but compatible) DLL
> comes out?  You'd only have to recompile if (a) you linked by ordinal
> instead of by name (AFAIK, cygwin-ld only links by name -- you can't
> link by ordinal) AND the library developer didn't use consistent
> ordinals, or (b) the DLL had an incompatible interface -- e.g. a major
> soname change.
> 
> However, versioning dlls down to the micro-revision level will cause a
> real headache, fast:
> 
> Q: why doesn't package X work? It says it requires zlib and I have it
> installed...
> A: you need version x.x.A of zlib, you probably have version x.x.B
> Q: okay, I removed version x.x.B and installed version x.x.A from the
> archived tarballs, and now package Y is broken
> A: well, package Y needs version x.x.B -- so you need to have both
> zlib-A and zlib-B installed if you want BOTH package X and 
> package Y to
> work.  Be sure install version x.x.A of zlib first, and version x.x.B
> last so that the import lib will link to the newer version of 
> zlib when
> you build package Z...
> 
> Aaarrrgghhh!!!!!!

Me too! 

> 
> You might as well link statically and forget you ever heard of DLLs.
> It'll sure cut down on support headaches.

Sure but complicates a lot updates of existing installs, as you pointed 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 :-(
> 
> Yeah...but you're trying to support ONE application.  Since 
> I'm porting
> libraries to cygwin, I'm concerned about supporting ALL packages that
> depend on those libraries -- both their developers and their 
> (sometimes
> clueless) users.
> 
> I also don't want developers of package XYZ complaining to me 
> or the to
> the list because XYZ depended on version a.b of some library, and I
> removed it from the standard installation and put version a.b+1 on
> cygwin to catch some bugfixes.  "Please put a.b back -- we'd 
> prefer that
> you did extra work and supported 83 old revisions of each of your 27
> libraries, rather than us using and supporting the use of the most
> bugfree version of your library...we like bugs..."
> 
> Not gonna happen. At least, not by me. I hate to put it this way, but
> unversioned libraries (other than incompatible interface 
> changes) FORCE
> developers of other packages to use & support the most recent, most
> bugfree version of the libraries.  I'm NOT gonna get sucked into
> supporting all the old revisions of every library I've 
> ported.  I've got
> enough to do answering the questions about only the most recent
> versions...
> 
> If someone else wants to take over maintainership of the umpteen
> libraries I've ported so far, and version 'em -- fine.  But 
> don't expect
> me to help answer the thousands of FAQs that'll suddenly show 
> up on the
> list.  Unless somebody comes up with a really good argument for
> versioned libs (beyond the *necessity* imposed by incompatible
> interfaces -- I'll grant that one) AND can explain how to minimize the
> support difficulties.
> 
> > 
> > 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 :-)
> 
> Until you neglect to upgrade to the newer versioned DLLs, and have to
> ship the old versions of the versioned dlls to everybody who uses your
> app.  Then your exec download is much heavier.
> 
> To me, the absolute best #1 *benefit* -- not drawback -- of DLLs and
> shared libs in general is that you can 'slipstream' update 
> all dependent
> apps without recompiling. 

I 100% agree; the volume of code is only slightly important fro me too; it's
just a bit faster to burn a 400Meg CDROM than a 600 one :-) 

The only reason I'm switching to DLLs is the upgradeability they bring me.

> 
> sure, when there's a major, incompatible change in the interface
> (so-name, in unix parlance) we might have to revisit this issue.  For
> instance, libpng-2.x.x (still in alpha) is incompatible with older
> apps.  It'll definitely have to be libpng2.dll. But for micro- and
> minor- version changes, I don't want to deal with versioned 
> dlls and the
> INEVITABLE support NIGHTMARE that will ensue.  You think non-versioned
> DLLs are a support problem? just wait...

Sure minor/micro versioned DLLs would be real nightmare! 



> 
> --Chuck
> 

--------------------------------------------
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@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com