RFC: Cygwin 64 bit?
Mon Jun 27 12:53:00 GMT 2011
On 27/06/2011 8:11 AM, JonY wrote:
> 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
> How does that happen for per-app?
Actually, in retrospect, I think it would happen automatically. If I
understand correctly, Windows always searches the binary's own '.'
first, followed by %PATH%. That would cover loading of static libraries,
dlopen, and fork. So, if the user starts an N-bit app and then forks
some app having both 32- and 64-bit versions available, Windows would
select the N-bit version unless the file name given forces use of the
Given that, the earlier suggestion to put 64-bit binaries first in the
path probably makes the most sense.
>>>>>> - 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?
Something like Wow64, I guess. Most winapi calls have a pretty narrow
interface as far as long/LONG goes, so it shouldn't be too hairy to make
the conversion. Also, for anything exotic, the target audience is
Windows programmers using cygwin, and they'll be using LONG properly
If LONG != long, we'll also have to worry about the inevitable posix app
defining conflicting typedefs, but hopefully that wouldn't import the
More information about the Cygwin-developers