Avoid collisions between parallel installations of Cygwin
Larry Hall (Cygwin Developers)
Thu Oct 15 06:18:00 GMT 2009
On 10/12/2009 12:28 PM, Corinna Vinschen wrote:
> this is sort of a follow-up to a mail from Earnie:
OK, I realize I'm chiming after allot of discussion has already taken place
but I figure better late than never. ;-)
First, I think it's great to open up a discussion about possible solutions to
the whole multiple cygwin1.dll situation. This is certainly one of those
that's reoccurring and it would be *so* nice if there was a way to retire it for
good. :-) Since I've had the advantage of reading through all the
discussion so far
(and finding the answers to some of my questions in the process), I'd like
on two areas that haven't been discussed (much?) yet in this thread.
1. I don't want to imply that Corinna hasn't done allot of good work with
(which she certainly has!) but I also want to look at this from the
"Devil's Advocate". So, most succinctly, one question that pops to mind
is "Is this
the best way to address this issue?" Certainly one could characterize
of multiple Cygwin DLLs as our own strain of "DLL Hell" and in this
supporting multiple DLLs fits with the common solution to the generic
However, we do have an issue which is definitely not so common, the shared
memory. So this got me to wondering "Is the common solution to 'DLL
right one for Cygwin?" I know, now everybody is waiting for me to
question. ;-) I'm not going to. I wouldn't be a proper "Devil's
Advocate" if I did.
However, perhaps the more interesting thing is to explore the
possibilities if the
answer is "No". What else could we do? Well, since this implies we'd
need to make 1 DLL work for everyone, we'd need to make it easier for
everybody to use that DLL. This has been discussed some in the past
but I think the key point would be that there would need to be an easy
way to find and update the installed DLL. I think if we had some kind
of registry (yeah, I guess we could even use the Windows one if we had
to ;-) ), this would solve the "where do I look" problem. Obviously
trade-off to this as well, since the user is still limited to one DLL.
would be an approach that would allow 3PPs to install in a compatible way
with Cygwin and vice versa. I expect there are some other possibilities out
there that could serve as a solution in the "No" case too.
2. Now assuming the Devil is sent home unfulfilled, ;-) I've been doing some
thinking about what multiple Cygwin DLLs in their own little worlds
perhaps more importantly, what kind of problems that we haven't seen before
because we always stopped at the "1 Cygwin DLL" door will surface now that
the door as well as the whole side of the building is gone. ;-) I know
an incomplete list but here's a few things I thought of:
A. A user has a Cygwin installation and the "Nifty-Difty Ultimate SSH"
Surprisingly, "Nifty-Difty Ultimate SSH" hangs for some reason (it has
a bug - who
knew this could happen) and the user tries to kill it using Cygwin
tools. The user
sends email to the list asking why he can't find and kill the
SSH" process using Cygwin's 'ps' and 'kill' (not '/bin/kill -f').
B. A user has a Cygwin installation and a 3PP with a cool new command-line
tool that filters stdin. User dumps the output of a file using
Cygwin's 'cat' and
then pipes it into the new 3PP command-line tool and gets nothing. The
user contacts the list to ask why.
C. A user has a 3PP file browser. After subsequently installing Cygwin,
user sends email to the list asking why Cygwin's view of the file system
doesn't match that of the 3PP file browser.
So where we had one issue before, all classified under 1 big category of "1
Cygwin DLL" which was pretty easy to diagnose and had a very direct answer,
I'm wondering how many new offshoots of this we're "trading up" to, if we
allow multiple DLLs to coexist out there in user land. But even putting
possible multiplication of issues, there's a potentially more important
issue of how
are we going to be able to diagnose these issues so that we know these are
"you're using multiple Cygwin DLLs" issues and not some other bug in Cygwin
that needs addressing? Certainly it seems to me that we need some
tools (cygcheck?) to help us understand how many different DLLs are on
system and which ones are in use at least. Along that line of thinking,
it seems to
me that we could make use of a (the?) registry again to keep track of
Cygwin DLLs installed on a system and even which ones are loaded in
thinking here of the Cygwin DLL itself managing these entries, but I
don't want to
get too bogged down in details of this one diagnostic feature when I'm
concerned about any others that I most certainly haven't even dreamed
anyone started enumerating a list of "possible problems" that we may see
popping up on the list if we allow multiple, disjoint Cygwin
environments in the
wild? Should we be trying to think of the potential problem areas so
can assure ourselves that we have a good chance of being able to classify
them and offer responses and solutions (or policies) for them?
OK, I think I've said enough for now. If it's worth delving into the
details of any of
these areas, I'm happy to discuss them further. But I think it's best I
don't get too
tedious (if that's even possible! ;-) ) with my first reply at least.
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
216 Dalton Rd. (508) 893-9889 - FAX
Holliston, MA 01746
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?
More information about the Cygwin-developers