This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Cygwin 64 bit?


On 7/7/2011 7:26 PM, Yaakov (Cygwin/X) wrote:
The path from which the application started is always first.  The
current working directory is always prior to the paths from $PATH.
Whatever you do, if you're in the wrong dir it goes boom.

So if the DLLs were in /usr/lib{,64}, and we started a 64-bit program with CWD of /usr/lib, then it goes boom. Under what circumstances would CWD be /usr/lib* that this would be a concern in the first place?

Why _shouldn't_ CWD be /usr/lib? What if I want to look for a symbol in some library? What if I'm doing system maintenance? What if I'm just looking around? Why should ls(1) go boom if I run it in /usr/lib? Using PATH adds quite a few failure modes, and I'm still having a hard time seeing the purported benefits over the separate-prefix approach.


I'm dreaming here trying to get past
this issue for cyg128.  If every use of a library were RUN TIME instead
of LOAD TIME then you can segregate easier the library bitness into
differing directories such as lib64.

I still don't see the problem t use a cyg64 prefix. It fixes almost all problems, and the potential problems with dynamic loading can be handled within dlopen.

Wouldn't changing dlopen() to compute absolute paths for LoadLibrary() be easier (and perhaps safer) than changing the former to manipulate various permutations of DLL names?

All other things being equal, sure. But because separate prefix is necessary anyway, the permutation approach might as well be used.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]