Re: DLL naming conventions

[Charles Wilson <cwilson at ece dot gatech dot edu>]

<<warning. this message is controversial. please read the entire thing
before responding...>>

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.

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

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

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

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

--Chuck

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