This is the mail archive of the
mailing list for the Cygwin project.
Re: Problem with cygwin1.dll and xfree
- From: Rasjid Wilcox <rasjidw at openminddev dot net>
- To: cygwin-xfree at cygwin dot com
- Cc: cygwin at cygwin dot com
- Date: Tue, 9 Jul 2002 23:16:58 +1000
- Subject: Re: Problem with cygwin1.dll and xfree
- References: <email@example.com>
On Tue, 9 Jul 2002 5:26 am, Dr. Wayne Keen wrote:
[Post on firstname.lastname@example.org]
> I know I have run into problems a couple of times with programs that
> have windows installers that somehow like to assume that you don't
> already have Cygwin on your machine.
> The first time I installed Octave, it replaced my Cygwin with some
> minimal installation it needed to support itself.
> Something not as severe happended when I ran an Windows installation
> program for Ruby.
> Eventually....I learned to just go ahead and build things myself
> within Cygwin.
The main reason I stopped distributing the original version of my Minimal
Cygwin-XFree86 for XDMCP only install was my gradual (and slightly belated)
understanding of this problem. And it was only because of discussions on the
cygwin-xfree mailing list that I discovered this problem at all.
Personally, I think the requirement for there to be only a *single*
cygwin1.dll needs to be *far* more strongly emphasised on the Cygwin website,
in somewhere prominent (like on http://www.cygwin.com/index.html).
As the porting of open-source software from Linux/Unix to Windows becomes more
common, unless things change this problem is only going to get worse.
The problem here is that many developers are going to want to distribute their
program Windows ports via a Windows installer, not via Setup.exe. And they
are going to want their program to install as transparently as possible, so
they are going to provide their own copy of the cygwin1.dll on the assumption
that the user probably wont already have one. This is generally true
currently, but will become less true as time goes by.
I know that the Windows port of MySQL relies on the cygwin1.dll. And in my
wanderings I have seen several others (Ruby and Octave are mentioned above).
It is no good if each program puts the cygwin1.dll in it own directory, since
if two of the programs are running at the same time there may be problems.
It is even worse if they all try and put it in system directory, since then
who knows what version you will end up with. And regardless of what happens,
if the user either has or later installs Cygwin via Setup.exe there will be
The only long term solution that I can think of is to make it possible
(perhaps it already is) for the Windows installer to use an automated version
of Setup.exe, that without any interaction from the user (unless absolutely
necessary) will install or update (if required) the cygwin1.dll in a
Setup.exe compatible way.
That way, if I install program A which depends on the cygwin1.dll, and then
install program B (which has an older version of cygwin1.dll) it just leaves
the newer version there. If I then install program C which requires a newer
version, the dll is then updated by the automated setup.exe. If I then
install Cygwin via Setup.exe, it just notices that I already have the
cygwin1.dll and only updates it if necessary.
I think that basically what would be required would be to enable Setup.exe to
be controlled by a config file (similar to a RedHat kickstart file), and have
its GUI not displayed unless there was a problem and user interaction was
The other thing required is education. Existing projects that use the
cygwin1.dll need to be informed of the issue and encouraged (gently) to help
do something about it. And the information about the conflicting dll problem
needs to be much more 'in the face' of potential cygwin1.dll users.
No doubt, ideally all cygwin based programs should be installed via Setup.exe,
and then the problem goes away. Realistically, that is not going to happen.
'Ordinary' Windows users (as opposed to cygwin users) like Windows
installers. And when programs that use the cygwin1.dll start crashing
randomly due to multiple cygwin1.dll copies, Joe Windows User will simply see
an open source program failing to work, and decide that he will stay with
closed source programs after all. That is what concerns me the most.
Anyway, that is my 2 cents on the issue. Perhaps this has already been
discussed in depth before and/or is already implemented or in the process of
being implemented, and if so my apologies if I'm wasting bandwidth. I'm not
subscribed to the cygwin list, only cygwin-xfree. I'm CC'ing the cygwin
list, since I think it is fundamentally a cygwin issue, not an Cygwin-XFree
issue, although of course it effects anything that depends on cygwin.
> So, one message that probably should leak out is to avoid Windows
> binaries that mention anything about Cygwin. :-)
I would be inclined to check anything that was developed on Unix/Linux first
and then ported to Windows, even if they fail to mention Cygwin, and even if
it is closed source. But perhaps I'm just paranoid. ;-)
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html