RFC: Cygwin 64 bit?

JonY jon_y@users.sourceforge.net
Mon Jun 27 12:12:00 GMT 2011

On 6/27/2011 20:00, Ryan Johnson wrote:
> 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.

How does that happen for per-app?

>>>>> - 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*).

So, some sort of thunk server/client thing in between the Cygwin DLL and
system DLL?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xED74C077.asc
Type: application/pgp-keys
Size: 1685 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-developers/attachments/20110627/f4366337/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://cygwin.com/pipermail/cygwin-developers/attachments/20110627/f4366337/attachment.sig>

More information about the Cygwin-developers mailing list