RFC: Cygwin 64 bit?
Tue Jun 28 16:36:00 GMT 2011
On 2:59 PM, JonY wrote:
>> - What name should the 64 bit DLL have?
> I think they should still use the "cyg" prefix, the libtool people was
> against it when I suggested using a new prefix for 64bit mingw.
Not /this/ libtool person. I would LIKE to be able to distinguish
between 32bit and 64bit DLLs on both cygwin and mingw. I'd support a
change to libtool for cygwin64 DLLs to have an alternate prefix
(cyg64*?), and (if it's not too late, horse/barn situation) I'd also
support a similar change for mingw64.
>> - Where should 64 bit binaries and libs go?
> Its best that if we can separate 32bit/64bit completely, so there won't
> be any conflicting files.
Mmmm...depending on the answer to the next question, maybe not. Since
we have a googleplex of applications that would need to be "ported" to
64bit, it won't all happen at once. Is the "separate" 64bit distro
going to be crippled until ALL of the projects are ported?
I prefer being able to "upgrade" slowly from 32bit to 64bit, by
intermingling the apps. But, this requires
(a) cygwin64-1.dll(?) and cygwin-1.dll being able to share data
(b) ABI/API consistency. If zlib1.dll defines an interface that takes
a (32bit) "long"...but my 64bit version of tar.exe thinks that a long is
64bits...it might break if linked to the 32bit version of zlib1.dll.
Does this mean that ALL DLLs must have 64bit implementations before ANY
client EXEs are ported to the 64bit "platform". That's another
"crippled until" non-solution...
>> - Do we define "long" as 32 bit or 64 bit type?
> I suggest 32bit, they'll be some awkwardness accessing w32api at the
> Cygwin backend if they're 64bit.
Right, but then you have sizeof(long) != sizeof(void*). That's really
bad, from what I understand.
>> - What defines should a 64 bit Cygwin compiler define?
> __CYGWIN__ and __CYGWIN64__? Just so to allow programmers to tell that
> its cygwin and its 64bit.
>> - What Windows headers and link libs do we use?
> Bootstrap with mingw-w64? :)
Hoo-boy. There are some issues there, which deserve their own thread --
so if you want to open this furball, please reply-to with a new subject.
1) there are concerns that mingw64's w32api header provenance is not
IP-clean. The mingw64 folks deny this, and even have a good argument
that mingw.org's w32api provenance is not as supposedly IP-clean as
claimed. But, if cygwin (a Red Hat product) is to go in this direction,
then Red Hat legal needs to get to the bottom of this. Fortunately
(unlike mingw.org), mingw64 has corporate backing -- and a legal
department -- from Kai's employer. So, there's a possibility for some
lawyer-to-lawyer resolution here, rather than hashing stuff out on a
mailing list by non-lawyers.
2) *completely* different mingwrt/w32api headers for 32bit cygwin and
64bit cygwin just seems like a really bad idea.
>> - How much interest do you have in a 64 bit Cygwin?
>> - How much interest do you have to help to make 64 bit Cygwin real?
interest...check. time...limited, as always. But I'll do what I can.
>> - What part of the project would most interest you to help? Coding
>> Cygwin? Documentation? Setup? Toolchain? You name it.
Toolchain, and resolving the w32api/mingwrt issues.
More information about the Cygwin-developers