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: <39AF2210.E58D9F72@ece.gatech.edu>
Date: Thu, 31 Aug 2000 23:27:12 -0400
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
MIME-Version: 1.0
To: Paul Sokolovsky <paul-ml AT is DOT lg DOT ua>
CC: cygwin AT sources DOT redhat DOT com
Subject: Re: DLL naming conventions
References: <19558 DOT 000830 AT is DOT lg DOT ua>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I just want to announce that I don't know what I'm talking about when it
comes to the 'standards' for versioning shared libraries.  I just did
some research, and the following assumptions of mine were completely
wrong:

given package name "foo-X.Y.Z"

I stated that
 1) "X" was incremented due to source-level incompatibilities (API
changes)
 2) "Y" was incremented due to binary-level incompatibilities (ABI
changes)

wrong on both counts. Package name versions have NOTHING to do with
API/ABI changes -- unless the maintainers are 'nice'.  Sometimes they
are.  But assertion #2 is almost certainly wrong.  Anyway, maintainers
are perfectly free to bump X because their dog died.  They can bump Z to
indicate a complete rewrite from the ground up.  Whatever.

So, API/ABI interface compatibility can be orthogonal to package
versioning.  (*)

See the following two documents, but don't draw any conclusions until
you've read both

1) on shared libary naming conventions
  http://www.debian.org/Lists-Archives/lsb-spec-9905/msg00011.html

2) on interface (API/ABI) versioning
  http://www.gnu.org/software/libtool/manual.html#Versioning
  http://www.gnu.org/software/libtool/manual.html#Release%20numbers

(*) This explains Chris's suggestion earlier in this thread: 

> In your case, though, I don't see that there will be a problem until
> there actually is an API change.  When that happens you can add a
> '1' to whatever DLL changed.

e.g. maintain API/ABI version numbers orthogonal to package versions,
just like cygnus does for the cygwin dll.

This makes me happy. I like this answer to the versioning question. The
'cyg' prefix question is still up in the air -- but only for 'my'
/contrib libraries, not the official /latest libraries. (Chris has
already said he's sticking with libfoo.dll for the official cygnus
packages).  However, I'm leaning against 'cyg' too, given the solution
presented earlier in this thread:

> That means that the (so far hypothetical) DLL problems should be
> solvable by keeping the DLLs in the same directory as the executables.

Since all /contrib and /latest dll's & executables go into /usr/bin (==
/bin), the only problems -- within the cygwin sandbox -- imposed by this
solution are other cygwin packages that are installed into /usr/local/
but depend on dll's in /usr/bin.  Those problems can be fixed by
  1) cp /usr/bin/*.dll /usr/local/bin  !! YUCK !!
  2) insure that the path gets /usr/bin before /windows/system or
whatever
This works -- in the sandbox (e.g. Michael Ring's User1: see
http://sources.redhat.com/ml/cygwin/2000-08/msg01241.html)

> User1 is happy with cygwin as as 'linux light' on his pc. He uses
> cygwin only in it's own environment (means he first starts bash with
> the cygwin-icon and then works from within bash), his path will only
> include applications that reside inside the cygwin-tree.

However, what of Michael's User2: ?

> User2 is a NT-User who has found out that the standard tools that come
> with Windows/NT are not powerfull enough to assist him in doing his
> daily job. This user will have the cygwin directories somewhere in his
> path. And here the fun begins. 

Still NOT a problem -- for the official cygwin programs -- since the
executables live in /usr/bin (== /bin) and the dll's are there, too. 
The only problems are those local cygwin apps that do not live in
/usr/bin.  User2 cannot play PATH games -- or his non-cygwin apps which
depend on dll's with names similar to cygwin's will get the cygwin dll's
by mistake. So, he must 
   1) cp /usr/bin/*.dll /usr/local/bin (yuck)
   2) on NT/2K: ln /usr/bin/*.dll /usr/local/bin/...  
          hardlinks will work, I think
   3) or put the non-cygwin app's dlls into its executable directory
(this applies as well to other Unix-on-windows systems; they're free to
use a 'pw' prefix or whatever instead of lib, or just insure that all
executables reside in the same directory with their dll's like cygwin is
trying to do.

So, it seems to me that changing the library prefix is not really
necessary -- since there are less intrusive ways to fix the problems.

Hasn't this discussion been fun?  &-P

--Chuck

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