RFC: Cygwin 64 bit?

[Daniel Colascione]

On 7/8/2011 3:56 AM, Ryan Johnson wrote:
> On 08/07/2011 5:56 AM, Corinna Vinschen wrote:
>> On Jul 8 03:57, Yaakov (Cygwin/X) wrote:
>>> Did I miss anything? It seems that Windows already skips by "wrong-bit"
>>> DLLs, regardless which is in CWD or first in PATH.
>> Thanks for performing these tests. I still have to see it with my own
>> eyes :}
>>
>> OK, let's assume DLLs with the wrong bit-ness are skipped on
>> CreateProcess
>> as well as on LoadLibrary. What are the implications for us?
>>
>> - If we use the same "cyg" prefix, we have to split the /bin directory
>> into a 32 and a 64 bit bin directory, or
>>
>> - if we stick to a single /bin directory, we have to use another prefix
>> like "cyg64", or
>>
>> - we have to put the DLLs into a separate directory like /usr/lib64.
>> Separate directory has the problem that it always has to be in $PATH,
>> which is not such a good idea, IMHO.
> Given that Windows' loader is actually sane, I think I would favor
> having two bin dirs.***

With the two-bin-directory approach, if we have cygfoo.dll in CWD and 
run a program foo.exe also in CWD that links to cygfoo.dll, then whether 
foo.exe uses the CWD's cygfoo.dll or the system cygfoo.dll depends on 
foo's bitness, the precise ordering of PATH, and the bitness of the 
system. How would I tell what happened given only the DLL basename? 
Today, foo will use the CWD cygfoo --- that's bad, but at least it's 
consistently bad. Similar arguments apply to directories on PATH. Also, 
not all binaries live under /bin --- for example, I have a ~/bin. Am I 
supposed to have a ~/bin64 too?

A new DLL prefix has a one-time cost for tool updates, and from then on, 
it's a more mechanism with fewer moving parts, meaning fewer things that 
can go wrong.