Mail Archives: cygwin/2005/03/29/17:49:29
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/
- Raw text -