Why /usr/bin/*.dll must be executable?
Mon Apr 23 23:55:00 GMT 2012
On Mon, 23 Apr 2012, Larry Hall (Cygwin) wrote:
> On 4/23/2012 3:01 PM, Warren Young wrote:
> > Options 2-5 in the list at the page linked above don't really apply here.
> > Cygwin purposely keeps itself nice and segregated from the rest of the
> > system, so installing DLLs under c:\Windows isn't an option, and CWD is
> > simply useless for our purpose here.
> While the windows and system directories aren't a great place to be putting
> DLLs that don't belong to the O/S in some way (and indeed Windows tries to
> discourage it actively in recent versions by keeping it off limits to
> users without sufficient privileges), why do you think Cygwin apps
> wouldn't see a DLL it needed if it were in one of these locations?
> I'm in full agreement that the 16-bit system directory and "current"
> directory aren't useful or appropriate options in the context of
> locations for Cygwin DLLs.
Hmmm... I was following this thread hoping to learn something about a
problem I was trying to solve wherein I launch a Cygwin-GNU-compiled
program and it failed with "error while loading shared libraries: ?:
cannot open shared object file: No such file or directory".
(I think the question mark stands where there would ordinarily be the name
of some DLL, but I only received the question mark.)
...It seemed reasonable to think the problem may be related to where the
.dll files go, PATH, or some other clue given on the web page cited
earlier in this thread regarding the search order for shared libraries,
but I eventually traced it to something that seems bizarre to me: the use
of --login on a call to bash. Pre-Windows 7, this code was known to work
fine without the login switch and it drove me banannas until tried
--login. I'm wondering; what on earth would --login have to do with where
the dlls are found?
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin