This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [PATCH] setup: port to 64-bit, part 2
On Sun, 17 Mar 2013 13:58:10 -0400, Christopher Faylor wrote:
> Btw, was it announced that Yaakov was working on a complete 64-bit
> release? I knew that this was a possibility but was it actually
> announced that there would be a release area in cygwin's ftp area with
> packages (presumably) built by him?
>
> I don't recall seeing any email about this. It seems like this deserved
> a message to cygwin-apps with a clear subject discussing what was
> happening.
What's happening right now is just bootstrapping. Corinna released her
64bit toolchain for the first time five weeks ago, and the ABI
stabilized (I hope) less than two weeks ago. Since then, we've been
working to get enough packages built to enable basic usage and
development, so that others could test, and start building other
packages for, x86_64.
We're now at the point that both cygwin and gcc can be built natively,
and cygport git master is functional. Of course, there are still
bugs to be fixed and probably more that have yet to be found, but I
believe we will soon be in the position to help maintainers with porting
their packages to x86_64 in a few ways:
1) For those with 64bit systems and a sense of adventure, they'll be
able to build natively once their packages' dependencies are available.
2) A 32-to-64 bit toolchain with all the available libraries is already
in Ports and can soon be moved into the distro. Maintainers with
cross-compilable packages will be able to cross-build 64bit packages
with `cygport --64' once things stabilize.
3) Otherwise, we'll find a way to proxy build packages for x86_64.
Maintainers will still drive the development of their packages while
others take care of the actual build. (Which, when you think about it,
is exactly what happens with other binary Linux distributions.)
The goal is that a single .cygport and patchset (when needed) will work
for both i686 and x86_64, and that the packages in both distros will
end up having identical versions of all packages. Obviously some
changes will be need all around to make that happen, but that is
certainly the goal AFAIAC.
Yaakov