Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
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
Message-ID: <4249DB69.8090903@kleckner.net>
Date: Tue, 29 Mar 2005 14:49:13 -0800
From: Jim Kleckner <jek-cygwin1 AT kleckner DOT net>
Reply-To: Cygwin List <cygwin AT cygwin DOT com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Cygwin List <cygwin AT cygwin DOT com>
Subject: Re: clamwin installs incompatible copy of cygwin1.dll
References: <42430BDF DOT 90808 AT kleckner DOT net> <6 DOT 2 DOT 0 DOT 14 DOT 0 DOT 20050324141914 DOT 03d351d8 AT pop DOT prospeed DOT net> <424373E3 DOT 8060901 AT kleckner DOT net> <4243839B DOT 719CB945 AT dessent DOT net> <6 DOT 2 DOT 0 DOT 14 DOT 0 DOT 20050324221252 DOT 03c0d8a0 AT pop DOT prospeed DOT net>
In-Reply-To: <6.2.0.14.0.20050324221252.03c0d8a0@pop.prospeed.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

Larry Hall wrote:
 > At 10:20 PM 3/24/2005, Brian Dessent wrote:
 >> A symlink won't work, because it's Windows own loader that searches
 >> for and loads any .DLLs called for by an .exe. Windows does not
 >> understand symlinks as they are a Cygwin thing, so you can't
 >> symlink a DLL and expect it to load.
 >>
 >> NTFS does not support symbolic links but it does support hard
 >> links, see
 >> 
<http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/prkc_fil_baey.asp?frame=true>.
 >>  If the volume is NTFS, 'ln' will use this capability. On 9x or FAT
 >> it will make a copy (I think.)

Right, that is what I saw.  Symlink failed but hard link worked.

 > Right. It will. It's also worth noting that hard links break again as
 >  soon as you update either clamwin or Cygwin, even on NTFS volumes.
 > Alternatively, if you make sure that clamwin can see your Cygwin
 > installation, it will seamlessly work through Cygwin updates. But the
 >  only way you're going to get clamwin to work seamlessly through
 > updates of clamwin is to get clamwin's installation to change.

A compelling reason to not use hard links.

OK, one last attempt, in the spirit of PTC and to help fellow
travelers.  The existing FAQ entry at this location reads:
   http://cygwin.com/faq/faq_3.html#SEC50

     Is it OK to have multiple copies of the DLL?

     You should only have one copy of the Cygwin DLL on your
     system. If you have multiple versions, they will conflict
     and cause problems.

     If you get the error "shared region is corrupted" or "shared
     region version mismatch" it means you have multiple versions
     of cygwin1.dll running at the same time. This could happen,
     for example, if you update cygwin1.dll without exiting all
     Cygwin apps (including inetd) beforehand.

     If you're trying to find multiple versions of the DLL that
     are causing this problem, reboot first, in case DLLs still
     loaded in memory are the cause. Then use the Windows System
     find utility to search your whole machine, not just
     components in your PATH (as 'type' would do) or
     cygwin-mounted filesystems (as Cygwin 'find' would do).

Based on the information in this thread, I would suggest some
variation of the following additional paragraph at the end of
that text:

     When you find copies of cygwin1.dll remove all of them
     except the cygwin-installed version.  As a workaround, you
     might be able to make the offending application work with
     the installed DLL by adding the cygwin bin directory to your
     system path environment variable.  Although you could hard
     link the cygwin DLL into the location of the application
     directory containing the duplicate copy instead of changing
     the system path, this is not a good idea because when you
     update the cygwin package, that link will break and you will
     once again have two copies of the cygwin DLL.

Hopefully, this will help fellow travelers and is in the
interest of reducing the amount traffic on this list.  Such
common problems seem logical to me to document in the FAQ rather
than wasting the OP's time and everyone on the list.  If there
is a place where this is already documented, the FAQ should
point there.

If there is interest, I am willing to take a crack at pulling
together the information that is sprinkled in email threads
about how to avoid trampling on existing cygwin installations.

Eventually, there really should be a section in the user guide
about the topic "How (and how not) to create and distribute an
application that depends on cygwin".  I'm willing to help with
that but I suspect other people can write something many times
more quickly and more accurately.

Jim


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