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: <39AE7E06.CEFB0BC8@ece.gatech.edu>
Date: Thu, 31 Aug 2000 11:47:18 -0400
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
MIME-Version: 1.0
To: Earnie Boyd <earnie_boyd AT yahoo DOT com>
CC: cygwin AT sources DOT redhat DOT com
Subject: Re: DLL naming conventions
References: <20000831133952 DOT 21477 DOT qmail AT web123 DOT yahoomail DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Earnie Boyd wrote:
> 
> As Chris already pointed out, the solution to this for Cygwin is:
> 
> For any official cygwin/latest or cygwin/contrib package release the:
>        package should be configured with --prefix=/usr
>        .dll should goto /usr/bin.
>        .a   should goto /usr/lib.
>        no versioning controls on the names of the libraries.

But Paul is suggesting that the prefix for dll's be changed so that the
foo library is named:
   libfoo.dll.a (import lib)
   libfoo.a     (static lib)
   cygfoo23.dll

This will not affect build procedures at all, since -lfoo will find
libfoo.dll.a (which was built with '--dll-name=cygfoo23.dll' option),
and '-lfoo -static' will find libfoo.a.

The versioning of the dll will affect upgradability IMO. 

Not even Paul is suggesting that the version number change based on pico
or micro level library changes ( libfoo version X.Y.Z-A  --> version
X.Y.Z-(A+1) or version X.Y.(Z+1)-A  would still have the same version
number: libfoo.X.Y.dll ).  This is because only the major and minor
version numbers mean that the interface has changed:

X means source-level incompatiblity: libfoo version X+1 will not ever
work with a package 'BAR' written for libfoo version X, unless you
modify 'BAR's source.

Y means object-level incompatibility: libfoo version X.Y+1 can be used
with package 'BAR', but you'll have to relink/recompile BAR for that to
work. You can't 'slipstream' libfoo version X.Y+1 and expect BAR to
work.

With that understanding, I think that versioning the DLL's *only* based
on X.Y is okay. (I suppose the "right" thing is to also version the
import libs based on X, but I just don't have the energy for that...)

Now, the use of the 'cyg' prefix instead of the 'lib' prefix -- for
DLL's *only*, not import libs -- is a whole 'nother can of worms. See
below.

> 
> For any unoffical cygwin package release the:
>        package should be configured with --prefix=/usr/local/package-x.x.x.
>        .dll should goto /usr/local/package-x.x.x/bin.
>        .a should goto /usr/local/package-x.x.x/lib.
>        .exe should goto /usr/local/package-x.x.x/bin.
>        .info should goto /usr/local/package-x.x.x/doc/info.
>        man files should goto /usr/local/package-x.x.x/doc/man.
>        html files should goto /usr/local/package-x.x.x/doc/html.
>        etc.
>        no versioning controls of the names of the libraries 

I'm not so sure about the versioning controls on DLL's, here, either.

> unless the
> libraries use shared memory regions that may conflict with other libraries of
> the same name.

Okay, now I am confused.

If two libraries have the same name, don't they automatically conflict? 
Windows loads the first one it finds into memory, and every executable
thereafter will use that copy, right?

Suppose the following:

The native Win32 port of GIMP uses libz.dll and libtiff.dll (compiled
natively, so no dependence on cygwin1.dll). Tor Lillqvist distributes
libz.dll and libtiff.dll bundled with his native Win32 GIMP (installed
into the same directory as the executable). Clearly, these two dlls are
incompatible with the cygwin libraries of the same name, and vice versa.

I built a cygwin XEmacs that depends on the cygwin libz.dll and
libtiff.dll.

Now, I run GIMP. Naturally, since the windows dynamic loader looks in
the directory of the executable before searching the path for any
dynamic dependencies, the GIMP/windows-native versions of libz.dll and
libtiff.dll are loaded into memory.

Then, I run cygwin-XEmacs.  Does the windows loader even try to locate
libz.dll or libtiff.dll -- or does it just use the (windows-native) ones
in memory?  Or does it try to load them, and not finding them in the
xemacs executable directory, searches the path and finds them in
/usr/bin and loads the cygwin-versions? If the windows loader DOES load
the cygwin-versions, do they then conflict in memory -- or do they
conflict only if they use shared memory regions....

How do you tell if a dll uses shared memory regions?

--------

Anyway, the more I ponder, the more I think using 'cyg' prefix on dll's
is a good idea -- Chris's objections notwithstanding.  Yes, cygwin was
here first.  But, by sticking to the 'libfoo.dll' name, we rely on the
good nature of the other unix-on-windows layers to not interfere with
us.  Or that other application packages will not interfere with us. 
Personally, I don't trust 'em. :-)

If we use a 'cyg' prefix, then its VERY unlikely any external executable
or package will ever screw up a cygwin installation through dll
conflicts.  We may, however, need to submit another patch to ld, so that
we restore the ability to link directly to dll's -- e.g. make ld 'know'
about the cyg prefix.

(This argument is based on the supposition that dll's with the same name
will always conflict. If I'm wrong about that supposition, please
correct me...as I stated above, I'm a bit confused as to when dll's will
conflict and when they will not)

--Chuck

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