On Mar 19 11:57, Yaakov S wrote: > Corinna Vinschen wrote: > > From a POSIX perspective it's > > wrong to rely on the default Win32 DLL load order in dlopen() and the > > behaviour of dlopen() in 1.5.25 was a bug rather than a feature.
I spoke nonsense here. See below. > > Bottom line is, I'm sure the new behaviour is more correct, but if > > you have a convincing argument to revert to the old behaviour, I'm > > certainly open for discussion. > > First, it's a huge regression. This breaks *lots* of existing code. > > Now, at risk of stating that which you already know quite well: > > Using /usr/lib as the default LD_LIBRARY_PATH makes sense on *NIX > platforms where the shared libraries are themselves in PREFIX/lib, and > LD_LIBRARY_PATH is used not only by dlopen() but by ld.so for runtime > linking as well. > [...] > How could we proceed? > > We could keep the code as is, but since we install DLLs to /usr/bin and > add it to PATH, we need to add it to LD_LIBRARY_PATH as well. Those who > add /usr/local/bin (or ~/bin) to their PATH will need to add it to their > LD_LIBRARY_PATH also, so you end up with nearly identical PATH and > LD_LIBRARY_PATH values. > > OR we could revert the code to allow searching in PATH as before, since > that's where the DLLs actually reside. The SUSv4 dlopen man page clearly states "If file contains a <slash> character, the file argument is used as the pathname for the file. Otherwise, file is used in an implementation-defined manner to yield a pathname." The best match for the implementation-defined manner under Cygwin is probably the DLL search algorithm of Win32. I'll revert that patch in a couple of minutes. Thanks for the report, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
