RFC: Cygwin 64 bit?

[Ryan Johnson]

On 26/06/2011 8:52 PM, JonY wrote:
> On 6/27/2011 01:59, Corinna Vinschen wrote:
>> Right, but that wasn't what I meant.  Sorry for being unclear.  I was
>> talking about the name of the Cygwin DLL.  For instance, if we decide
>> that it must reside in the /bin directory, it must have a different name
>> than the 32 bit dll, for instance, cygwin64-1.dll.  If we decide that
>> all 64 bit applications and DLLs reside in a parallel directory, it
>> could have the same name, for instance, /bin64/cygwin1.dll.
>>
>> But let's not go into too much detail yet.
>>
> I was thinking that we have them totally separated, so we don't need to
> deal with DLL name clashes. Eg C:\Cygwin for 32bit and C:\Cygwin64 for
> 64bit. No need to invent bin32 or bin64.
++

We'll probably have to tweak %PATH% per-app, though -- 64-bit apps would 
need the Cygwin64 first and Cygwin second, with that reversed for 32-bit 
apps.

>>>> - Create a x86_64-pc-cygwin cross toolchain.
>>> Yeah, I suppose newlib has to be ported first.
>> Right, I forgot about that one.  But newlib works rather well for many
>> systems, so that shouldn't be much of a problem.
>>
> There's that hairy LP64 vs LLP64 issue, personally, I'd prefer the LLP64
> route since Cygwin is a translation layer and will need to communicate
> with Windows at the backend, but I suspect many more will want the LP64
> route for Posix software compatibility.
>
> I suppose there could be a minimalist Cygwin fork of the win32api to
> make it LP64 compatible. Maybe a thunk/translator layer will be easier.
I suspect we'll come out ahead in the end by following Linux and doing 
the translator -- the number of native windows apps compiled with 
cygwin-gcc (and which can't use mingw-gcc) seems a rather small fraction 
of the total, and posix apps could become a royal pain to compile on 
cygwin if sizeof(long) != sizeof(void*).