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