Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <39AEC3AD.42FE1CB9@ece.gatech.edu>
Date: Thu, 31 Aug 2000 16:44:29 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: cygwin AT sources DOT redhat DOT com
Subject: Re: DLL naming conventions
References: <20000831194146 DOT 867 DOT qmail AT web120 DOT yahoomail DOT com> <20000831154242 DOT B7880 AT cygnus DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chris Faylor wrote:
> 
> On Thu, Aug 31, 2000 at 12:41:46PM -0700, Earnie Boyd wrote:
> >--- Chris Faylor <cgf AT cygnus DOT com> wrote:
> >>
> >> That means that the (so far hypothetical) DLL problems should be
> >> solvable by keeping the DLLs in the same directory as the executables.
> >>
> >
> >Great news!  So my earlier suggestion stands to good effect.  Unofficial Cygwin
> >packages should install in --prefix=/usr/local/packages.x.x.x.  Official Cygwin
> >packages should install in --prefix=/usr.  No need to prefix, suffix or munge
> >the names.
> >
> >Done,
> 
> (Chris and Earnie shake hands and go about their business...)
> 
> (Other people not quite so satisified...)
> 

<g>

You're probably right about that.  Since (for the most part) official
binaries are in /usr/bin ( == /bin) and official dll's are in /usr/bin (
== /bin), then prefix/suffix/munging of dll's is a non-issue (see point
#1 below).

However, this doesn't address the question of versioning the DLLs, for
source-incomaptible changes and ABI (object-code incompatible changes)
-- e.g. versioning would help alleviate problems introduced when the
libraries become incompatible in these ways.  (I am not talking about
the core libs -- just the contrib libs like jpeg, tiff, readline...  I
am also talking here only of problems that could crop up inside the
'cygwin' sandbox -- the versioning issue is orthogonal to the issue of
other 'platforms' or applications which use similarly named dlls)

So, I guess I still have two unanswered questions:

1) I want experimental proof of the above 'solution'. I think I'll go
build a native libz.dll and play some games unless someone beats me to
it.

2) DLL versioning. While I'm not keen on redoing all the dll-ized
packages that I've ported so far, IF it is deemed necessary I could see
versioning NEW releases, but ONLY when the library in question goes
through an API or ABI incompatible change. 

----
For instance, right now libpng.dll is version 1.0.8.  Next week, say,
the png folks release 1.0.9. Fine -- the updated cygwin version will
still be libpng.dll.  Then, in a few months, the png folks release 2.0.0
(or 1.2.x). Ah -- that version will be libpng.2.0.dll or libpng.1.2.dll
(*) (but the import lib will be libpng.dll.a and will overwrite the old
import lib (**) ).
----

(*) Yes, I know it really should be libpng.3.0.dll (or libpng.2.2.dll)
since libpng-1.x.x is actually revision 2 of the API and libpng-2.x.x
will be version 3 of the API. It's just an example; don't get riled.

(**) Another controversial issue. Let's not discuss this one yet,
please.

Okay, restating my two remaining questions:

1) experimental proof that clever dll placement in the filesystem can
get us out of 'DLL hell'
2) should new libraries version their dll's when API/ABI changes?

--Chuck

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