Re: RFC: Cygwin 64 bit?

["Yaakov (Cygwin/X)" <yselkowitz at users dot sourceforge dot net>]

On Sun, 2011-06-26 at 13:45 +0200, Corinna Vinschen wrote:
> I'm not sure if you agree, but as far as I can see, 32 bit systems are
> more and more reduced to a niche market, namely Netbooks and other very
> small systems.  On the Desktop, 32 bit is declining fast, in the server
> segment it's practically dead.
> 
> Given this, I'm wondering how much future Cygwin has if we stick to
> 32 bit.  I think it will be pretty limited.  In fact, we're probably
> rather late in the game.

Compared to whom?  I run very little Windows-native software anymore,
but when I look at the large open-source projects, such as Mozilla,
Google Chrome, or LibreOffice, they still don't provide 64-bit Windows
binaries.  True, that's all desktop software, but I'll admit that
desktop software is my focus.

>   - What name should the 64 bit DLL have?

This depends on whether there will be any multilib support on x64
systems or not, and to what extent.

>   - Where should 64 bit binaries and libs go?

If no multilib, then just use /usr/bin and /usr/lib; forcing /usr/lib64
is more trouble than its worth.  If there would be multilib support, I
think it depends on the extent thereof.

>   - Do we define "long" as 32 bit or 64 bit type?

IIRC on Linux, x64 long is 64 bits.  Going against that assumption might
make it more difficult to build other FOSS software for Cygwin x64.

>   - What defines should a 64 bit Cygwin compiler define?

__CYGWIN__ and __X86_64__.  I think we want to avoid __CYGWIN64__ in
case MS trademarks "Win64", if they haven't already.

>   - What Windows headers and link libs do we use?

Good question.  mingw.org headers do not currently support x64, but
using MinGW-w64's headers would require a lot of changes.  (Trying to
build setup.exe with mingw64 certainly did.)  Unless the two communities
merge or it is apparent that only one will continue long term, then I
think we choose whichever would be easier, and use those headers/implibs
for both x86 and x64.

> - Create a x86_64-pc-cygwin cross toolchain.

Binutils and GCC already have PE32+ support thanks to MinGW-w64, so that
shouldn't be too difficult, at least for C/C++.

> - Create x86_64 replacements for x86 code and in general try to make the
>   Cygwin code 64 bit clean where it isn't so far.

Another question: which version of Windows x64 would we start with,
Vista or 7?  Yes, there was a 64-bit XP but that was a long time ago and
AFAIK never widely adopted.  Starting support from a later version would
allow us to #ifndef a fair bit of code (and autoloads) needed only for
2K/XP.

> - Decide how we can integrate 64 bit stuff into the distro.  Will we have
>   a 32 bit and a distinct 64 bit distro?  Or, should we stick to a single
>   distro?  If so, how do we separate 64 and 32 bit stuff?

Linux distros with which I am familiar provide separate repos for 32-
and 64-bit systems (i686 and x86_64/amd64), with the 64-bit repo adding
32-bit builds of certain libraries for running x86 binaries downloaded
from elsewhere.  Since that use case doesn't really apply to Cygwin,
multilib support shouldn't be necessary.

>   What is the best package layout?

One factor is that we would have to completely change how packages are
maintained.  Currently, maintainers are responsible for building their
own packages, but what if a maintainer only has a 32-bit system?  I
think we would need a buildbot-type system for building the actual
packages.

> This is a big project which can only work if we have help and support
> from the community.

True, but $ome $upport from RH wouldn't hurt. :-)

> - What part of the project would most interest you to help?  Coding
>   Cygwin?  Documentation?  Setup?  Toolchain?  You name it.

Toolchain, bootstrapping, and porting packages.


Yaakov