Any comments on the revised patch? Is there a better way to handle the realpath()/REALPATH() thing?
[Sigh. We don't need to bore the binutils people with this cygwin policy debate.]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.
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/
