This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: Re: RFC: Cygwin 64 bit?
On Tue, 2011-06-28 at 13:19 -0400, Charles Wilson wrote:
> You've already made the necessary changes so that DLLPREFIX takes on the
> correct #defined value based on $host. This is a relatively simple
> addition since you've already done all the hard work.
No it's not, but thanks for asking. :-)
> Because (a) they didn't launch the 64bit version until they had
> recompiled the entire distro for the new platform -- having the manpower
> to do that in a relatively short time span. We don't have that luxury;
> we'll be stuck without 64bit versions of lots of our distro for quite
> some time. While the 64bit distro is crippled, nobody will use it, so
> it will get less testing...and thus, even SLOWER development/deployment.
Right, you can't test binaries that don't exist yet. How does it help
to have 32- and 64-bit binaries in one tree instead of two when you have
exactly the same number of 64-bit binaries?
Your arguments would be equally solved with the ability to run 32- and
64-bit distros side-by-side, and I agree that that is essential. But
the use case for multilib on Linux is so that users can download and use
32-bit-only binaries from third-parties, and that really doesn't apply
to Cygwin.
As for the time it will take to get a fully operational 64-bit distro,
there are steps we can take now to help expedite things:
* Currently package maintainers are free to choose package building
systems, so we have cygport, cygbuild, g-b-s, netrel, and who knows what
else. Agreeing on one would help both maintainer transitions and also
the following points.
* Currently there is no central repository for packaging sources. Other
distros all have one place where all packaging sources are kept, so that
all maintainers can see them, help out as necessary, make an emergency
update or add a patch when security vulnerabilities arise, and take over
more easily when others leave.
* Currently only package maintainers can initiate updates or rebuilds.
For example, if ncurses has another ABI bump (and its agreed that it's
actually necessary), then someone should be able to rebuild all
ncurses-dependent packages (without making other changes) for the new
version so that we don't need to keep old ABIs for years on end.
* Currently we're only a 32-bit distro, so anyone who can use Cygwin can
contribute a package. But when we support 64-bit, we can't expect all
maintainers to have a 64-bit machine handy. Having a buildbot system
would solve this and the previous point.
There are other points as well, but I'll stop here for now.
Yaakov