X-Spam-Check-By: sourceware.org
Date: Thu, 2 Feb 2006 16:42:57 -0500
From: Bob Rossi <bob AT brasko DOT net>
To: cygwin AT cygwin DOT com
Subject: Re: mismatched dll
Message-ID: <20060202214257.GB17485@brasko.net>
Mail-Followup-To: cygwin AT cygwin DOT com
References: <020220062132 DOT 11025 DOT 43E27A6B000117DD00002B1122007507440A050E040D0C079D0A AT comcast DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <020220062132.11025.43E27A6B000117DD00002B1122007507440A050E040D0C079D0A@comcast.net>
User-Agent: Mutt/1.5.9i
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Thu, Feb 02, 2006 at 09:32:27PM +0000, Eric Blake wrote:
> > 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

OK, I understand now, thank you. So, it would be possible to start
another process, that has a well known protocol, that distributes the
communication between dll's, instead of sharing the memory explicitly?

I'm just curious, I know this isn't going to happen.

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

Yeah, that's nice. However, what happens when this changes? 

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

I love Cygwin, so the following is not an attack against it, just
critism that one day could hopefully be resolved. The way Cygwin
currently can be distributed (as described above) is not 'packager
friendly'. If the user does happen to install your package (which has
cygwin1.dll in it) and then they install cygwin, the currently installed
package will no longer work.  I don't see any way to prevent this from a
packaging perspective.

As far as the licensing, Yeah, that's not a problem in any way.

Thanks for your help,
Bob Rossi

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