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: <39AEDDC9.D4315497@ece.gatech.edu>
Date: Thu, 31 Aug 2000 18:35:53 -0400
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
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> <39AEC3AD DOT 42FE1CB9 AT ece DOT gatech DOT edu> <20000831171339 DOT A15393 AT cygnus DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chris Faylor wrote:
> 
> On Thu, Aug 31, 2000 at 04:44:29PM -0400, Charles Wilson wrote:
> >1) experimental proof that clever dll placement in the filesystem can
> >get us out of 'DLL hell'
> 
> Haven't you seen people complaining about the "Shared region version
> mismatch" error with cygwin?  I really should have remembered this.

Ah yes. So, to make sure I understand, the shared region version
mismatch error is caused by:

you have two different cygwin1.dll's in the filesystem.

you run one cygwin app that loads the first cygwin1.dll into memory
(say, the app is in /bin and so it picks up the cygwin1.dll in /bin)

Then, you run another cygwin app that somehow picks up the other
cygwin1.dll (for instance, somebody for whatever IDIOTIC reason (*) put
an old copy of cygwin1.dll into \Windows\System, and has \Windows\System
in the front of their path, and this cygwin app is in /not/bin)

(*) don't do this. It's stupid, silly, and in all other ways a dumb
thing to do. You've been warned.

Blammo! Problem -- 'shared region version mismatch' since the two
different versions of cygwin1.dll are both trying to access the same
'shared region'.

Obviously, this proves that the windows loader will do what Chris and
Earnie (and others) have said. Problem solved. Almost:

Cygwin has libz.dll
GIMP has (a different) libz.dll (sorry to pick on you, Tor; I know you
don't even use the name libz.dll for your zlib dll, but let me use GIMP
as an example, okay?)
  -- assume for the moment that libz.dll uses 'shared regions' whatever
those are. DATA exports? I dunno.

You run a cygwin program from /usr/bin -- it'll load & use the cygwin
libz.dll in /usr/bin. Fine.

Then you run GIMP. It loads *it's* version of libz.dll. Blammo! Problem.
'shared region' mismatch or whatever. If libz.dll uses shared regions...

Or vice versa: you run GIMP first, and it works. Then you run a cygwin
app that depends on libz.dll and blammo!.

How can this problem be fixed, short of (a) never ever exporting DATA --
if that's what 'shared regions' are(???) or (b) using different names
for the dlls -- and we're back to the 'cyg' prefix, or assuming that all
those OTHER people will use different prefixes and leave us alone...

(niggling little question: do all dll's set aside a 'shared region'? or
only those that export DATA items?  If a dll doesn't use a 'shared
region' then you wouldn't see these sorts of errors, as long as the two
dlls were ABI/API compatible -- or would you? )

> 
> >2) should new libraries version their dll's when API/ABI changes?
> 
> Well, cygwin will when/if the API changes.  That's why it's called
> cygwin1.dll.
> 
> I went through my own private DLL hell to make this change.  Cygnus
> used to rename the DLL with every release so that executables built
> with last years DLL wouldn't work with this year's DLL even if there
> were only minimal changes in this year's DLL.
> 
> We used to name the net release DLLs based on the beta version, e.g.,
> cygwinb18.dll and cygwinb19.dll.  We stopped doing that with B20 since,
> for the most part, there have been no API changes since B18.
> 
> 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.

Done and done. (although, I'll probably add '.X' instead (or maybe .X.Y
if testing shows that the Y increment is binary-incompatible even if the
X (source compatibility marker) is unchanged). Whatever is the minimum
necessary versioning for application compatibility.

--Chuck

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