Mail Archives: cygwin/2005/03/24/22:15:54
Jim Kleckner wrote:
> This is helpful, thank you. Being curious and trying to be minimal
> about changes
> to the system in question, I tried removing and linking the dll in
> place. I first tried
> "ln -s /bin/cygwin1.dll" in the clamwin/bin directory and wasn't
> surprised that it
> didn't work. Being Unix person by background, I then tried "ln
> /bin/cygwin1.dll"
> and that surprised me by working. I expected to see an NTFS cygwin1.dll.lnk
> file in there but using "cmd.exe" and "dir" or the windows explorer
> looks like a
> full copy of the dll file. An "ls -l" tantalizingly shows a link count
> of 2. "info ln"
> doesn't give any cygwin-specific info. The section of the user guide
> located here:
> http://cygwin.com/cygwin-ug-net/using-effectively.html#id2950938
> has some wording that implies this might work but isin't definitive.
>
> My question now is, can "ln" be used to work around this issue or is
> that a "bad idea"?
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.)
You shouldn't need to do either though, as long as your original
cygwin1.dll from the Cygwin installation is in the path. Windows will
search for DLLs in: the directory of the .exe, the system directory, the
wondows directory, the current directory, and directories in the PATH,
in that order. See
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/loadlibrary.asp>
for details. So all you need to do is put \cygwin\bin in your path.
Care is taken by the maintainers to make sure the Cygwin DLL is
backwards-compatible, so the current cygwin1.dll should always be able
to replace any weird older Cygwin DLL that some installer uses (but not
the Bxx series.) However the reverse is not true, you cannot use a
binary that was compiled against a recent cygwin1.dll with an older copy
of the DLL. So in other words, all you have to do is ensure that you
only have one cygwin1.dll on your system and in the path, and that it's
the current version. Remove any other copies.
Brian
--
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 -