RFC: Cygwin 64 bit?
Mon Jun 27 12:01:00 GMT 2011
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
>>>> - 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*).
More information about the Cygwin-developers