Mail Archives: cygwin/2002/11/28/19:23:24
>>Any comments on the revised patch? Is there a better way to handle the
>>realpath()/REALPATH() thing?
> The only thing I like to say is, that instead of using a symbolic link to the
> dll, the "unix" way may be possible.
> What I mean is to put the dll into the lib dir (like the .so libraries in unix,
> the bin dir contains only executables) and to implement a LD_LIBRARY_PATH
> environmen support into cygwin1.dll, so that the dll could be used directly. But
> this is only an idea and there may be objectivies not to do so.
[Sigh. We don't need to bore the binutils people with this cygwin
policy debate.]
No, not really. The windows runtime loader handles loading the DLL, and
IT doesn't understand "LD_LIBRARY_PATH" and never will (closed source,
MS, yadda yadda). So it doesn't really matter whether cygwin1.dll
understands LD_LIBRARY_PATH or not -- cygwin1.dll is not involved in
loading DLLs (except for dlopen(), but that's a different subject).
Two choices:
1) put /usr/lib, /usr/local/lib, etc etc into $PATH
2) or do the symlink thing
Personally, I don't want to clutter the PATH with a bunch of lib
directories -- and neither do you, Ralf. You're always worried about
speed on cygwin, and proposing things like auto-rebasing and prelinking
and all sorts of disruptive things.
But according to MSDN, the one thing that slows program startup the MOST
is searching for DLLs in a long PATH. So, keep PATH short -- which
means the DLLs need to live in the 'bin' directories which are already
in the PATH. That means
we either put -L/usr/bin and suchlike into the gcc specs file (BLECH!)
or do the symlink thing. Me, I vote for symlinks. :-)
--Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -