From: ericblake AT comcast DOT net (Eric Blake)
To: Bob Rossi <bob AT brasko DOT net>
Cc: cygwin AT cygwin DOT com
Subject: Re: mismatched dll
Date: Thu, 02 Feb 2006 21:32:27 +0000
Message-Id: <020220062132.11025.43E27A6B000117DD00002B1122007507440A050E040D0C079D0A@comcast.net>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

> OK. I understand the concept of having each application share a single
> .dll, this is to save space. Unix does this with shared objects. 
> 
> However, here's what I don't understand. Please explain to me why 
> my thinking is fault. A program called p_v1 depends on v1.dll.
> Another program called p_v2 depends on v2.dll. For every p_v1 or 
> p_v2 you start, only a single version of the associated dll is opened.

The difference is not the .dll itself, but the shared memory region
that cygwin uses.  Every process linked against cygwin1.dll
opens a shared memory region, known by a fixed name/location, so
that information can be passed between cygwin processes
via this shared memory area.  And there are enough POSIX
semantics that require sharing info between cygwin processes
that it is QUITE difficult to try opening different shared
memory regions when different .dlls are used.

http://cygwin.com/cgi-bin/cvsweb.cgi/~checkout~/src/winsup/cygwin/how-cygheap-works.txt?rev=1.5&content-type=text/plain&cvsroot=src

http://cygwin.com/cgi-bin/cvsweb.cgi/~checkout~/src/winsup/cygwin/how-cygtls-works.txt?rev=1.1&content-type=text/plain&cvsroot=src


> 
> The reason this design is nice is because you can have multiple versions
> of the .dll installed, and they will be shared between executables
> nicely.

Yes, we know.  For example, /bin/cygreadline[4-6].dll all nicely
coexist, so that your application can choose which API level
of readline you want to use (4.x, 5.0 with 32-bit offset, or 5.x
with 64-bit offset).

> By moving the cygwin1.dll in the executable directory, things begin to
> work. However, I don't understand how it's assumed that the new
> cygwin1.dll acts the same as the one the executable was linked against.
> See what I mean?

There's a difference here.  Cygwin does not maintain binary
compatibility of its use of its shared memory region between
versions.  But it DOES maintain binary compatibility of the API
it exposes.  Cygwin releases try very hard to guarantee that
something compiled against an older cygwin1.dll will continue
to run when a newer cygwin1.dll is put in its place.  The
underlying details may change (such as the shared memory
region), but the API continues to work.  And that is exactly
what shared libraries were invented for.

> 
> Another reason I'm asking is, I was trying to think of how I could
> package CGDB for people.

By far the easiest is to tell them to download cygwin themselves,
then you don't have to worry about it.  But yes, this is not
very user-friendly.  So you will have to come up with some
scheme where if cygwin is already on the machine, you make
sure it is new enough for your needs, and if it is not present,
you make sure the user is informed that you are installing a
cygwin1.dll and that if they ever want more cygwin features
they should replace/delete the one you installed.  Otherwise,
you risk becoming the dreaded http://cygwin.com/acronyms/#3PP.

Oh, and remember that cygwin1.dll is GPLd, so if you distribute
the dll yourself, you must also distribute the source code for
the version you are shipping, as well as make sure your
own project is open source per the cygwin license.

--
Eric Blake

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/