Mail Archives: cygwin-apps/2000/05/17/10:13:34
> > Also, the path for the search for the .dll files
> > could be modified to search in more logical places such as /bin, /usr/bin,
> > /usr/local/bin and the windows system directory so that the symlinks wouldn't
> > be needed.
>
> Ugh. This would just confuse everybody. And I doubt the binutils or gcc
> guys would ever accept a patch of this nature.
>
Although you could do this when building gcc, by setting
"LIB_PATH"=/bin:/lib:/usr/bin:/usr/lib:/usr/local/bin:/usr/local/lib
Oh, and don't forget that in the future, when ./configure-ing a new
package (say rxvt), you'd *always* have to specify
--x-libraries=/usr/X11R6/bin:/usr/X11R6/lib to override configure's
default of path-to-X/lib.
Unless we got even sneakier, and had gcc munge its lib path at run time:
foreach component in libsearchpath
if endswith(compenent, "/lib") then
newcomponent = copy-of(compenent);
replace-end(newcomponent, "/lib", "/bin");
newpath = $newpath:$newcomponent:$component
fi
done
remove-duplicates($newpath)
libsearchpath = newpath
Double yuck. Violates principle of least surprise. I just think link
libraries should go in ..../lib, not ..../bin. So what if windows
requires the dll's to be in the executable PATH (typically composed of
.../bin-type directories). Cygwin can accomodate that by putting copies
of the dll's in .../lib (BAD) or symlinking (.../lib/foo.dll --->
.../bin/foo.dll).
Mingw (as opposed to cygwin-gcc -mno-cygwin). Hmmmm. Doesn't have
symlinks. Must think about this some more...but then, I never use mingw
so I'm not qualified; don't know the issues.
--Chuck
- Raw text -