At 05:49 PM 3/29/2005, you wrote:
>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
^^^^^
This should say "will".
> 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.
Beyond the email archives, no this isn't documented anywhere.
Judging by the previous responses to adding something like this
to the FAQ, for reasons already covered, I doubt this will be
added as part of the FAQ. But I don't speak for anyone but
myself.
>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.
I think this is a great idea, though perhaps this is more appropriate as
the basis for a "third party packager's guide". Although it is not really
hard to make a third party package that plays nice with Cygwin, if the
Cygwin site provides a helpful recipe and guidelines, there's a chance
we'll see more compliance, if only because we can then shame people into
it. ;-) If you're willing to put together the substance of this and neither
Chris nor Corinna dislike the idea, please post what you come up with to
this list. I, for one, would be happy to review your contribution.
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
838 Washington Street (508) 893-9889 - FAX
Holliston, MA 01746
--
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/
