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: <3BC5D8CE.7040301@ece.gatech.edu>
Date: Thu, 11 Oct 2001 13:37:18 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
MIME-Version: 1.0
To: Peter Buckley <peter DOT buckley AT cportcorp DOT com>
CC: cygwin AT cygwin DOT com
Subject: Re: Multiple cygwin installs: I have to do it, but how?
References: <3BC5B226 DOT 104 AT ece DOT gatech DOT edu> <3BC5C7B1 DOT BF4ABFB7 AT cportcorp DOT com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Peter Buckley wrote:

> I hope that Bob can read this message to the list, 
> if not, Chuck I hope will forward it to him.
> 
> My company ships some cygwin stuff, and most recently 
> we shipped a product containing some mixed executables and 
> cygwin1.dll and cygwinb19.dll. It didn't have any problems 
> because the names of the dlls were different. 


sort of.  The mount table entries are stored under the Cygnus Solutions 
key in the registry -- and both DLL's will look there for the 
information. So if the two "installations" require different mount 
tables, you could see conflict -- except that B19 stored the mount table 
undera slightly different subkey than 1.3.3 uses.  So, you might *not* 
see a conflict.  However, this is a non-solution: relying on a quirk in 
registry names that just-so-happens to distinguish between B19 and 1.3.3 
is not a long term solution.

OTOH, should we really bother to support old dists?  Isn't that their 
responsibility?  (BTW, I assume there ARE distributing the source code 
for their cygwin and linked applications, right?  Or did they purchase a 
support contract from Cygnus/Red Hat -- and if so, then this problem is 
a matter for Red Hat to resolve, not this public mailing list)


> I am currently renaming the cygwin1.dll to cw132cp.dll 
> and binary-editing (with emacs- don't try this 
> at home kids) the executables that depend on cygwin1.dll 
> to instead depend on cw132cp.dll. I guess I could recompile 
> them, but that would be extra work :-) 


This "solution" won't really work.  the cygwin dll uses a named memory 
area for sharing common data.  You are not changing that name -- so your 
cw132cp.dll-apps and your normal cygwin1.dll-apps will both access the 
same shared memory area.  Worse, cygwin1 won't know about cw132cp's 
access and changes.  This is bad.

You need to recompile cygwin itself -- and ALSO change the builtin 
shared memory name.  See the archives for info on how to do this.

(You might also think about using a different subkey in the registry for 
the mount table, for the same reasons.  This would also require changes 
to mount.exe in addition to cygwin1.dll)

> 
> So far everything is working okay- the executables run 
> just fine with the renamed dll. I think that it would be 
> very cost-effective for companies to rename the cygwin1.dll 
> to a version and company specific name, and then recompile 
> the cygwin tools they plan to ship with their product to 
> depend on the renamed dll. 


Except that as I have mentioned, that won't *REALLY* isolate their 
product from a standard cygwin dist.


> We were pretty sure none of our customers were using cygwin, 
> but we wanted to minimize calls to tech support about 
> "my cygwin is colliding with your cygwin." 
> 
> Even so, it seems like Altera wasn't very forward thinking 
> when they chose their mount points- Isn't it just common 
> sense that you wouldn't set / or /usr/bin or important things 
> like that?


IMO, the best solution here is for companies to isolate their specific 
apps into packages, and install their stuff as a cygwin package into a 
"normal" cygwin installation (if a normal cygwin inst doesn't exist, 
then install that, too).

It seems that most of what you're seeing is a historical artifact from 
the previous "all-in-one-big-package" method of distributing cygwin and 
dependent programs (e.g. B19 -- B20.1).  Since we now have split things 
up into smaller units, it makes sense for companies to follow suit, but 
these things take time.

--Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/