On Oct 18 17:57, Kai Tietz wrote: > Hi Corinna, > > 2012/10/18 Corinna Vinschen: > > Hi Yaakov, > > > > On Oct 18 02:33, Yaakov (Cygwin/X) wrote: > >> On Wed, 2012-10-17 at 15:32 -0400, Christopher Faylor wrote: > >>> But, anyway, nevermind. This shouldn't be a requirement for getting > >>> these changes checked in. I'm more concerned with just nuking the > >>> now-unneeded mingw script. > >> > >> Draft patch attached, based partially on Kai's. Yes, it needs a > >> ChangeLog entry, but it also needs more testing first. > >> > >> On Cygwin, you need either mingw-gcc-g++ and mingw-zlib, or > >> mingw64-i686-gcc-g++ with Ports' mingw64-i686-zlib, available here: > > > > Any problem to move mingw64-i686-zlib into the distro? > > Hmm, wouldn't assume so. I can give JonY a ping for that. I assume > he would provide such a package. Shall I ask him?
Actually I thought we just take the one Yaakov already provides on cygwinports: > >> ftp://ftp.cygwinports.org/pub/cygwinports/release-2/CrossDevel/mingw64-i686-zlib/ > >> On Fedora, you need my cygwin-gcc-c++ plus mingw32-gcc-c++ and > >> mingw32-zlib-static. Unfortunately F17's mingw32-headers isn't > >> (aren't?) new enough, so two files in winsup/utils wouldn't compile > > > > Indeed, unfortunately. The Fedora maintainer cut the latest version > > right before I started to apply my changes to mingw64. > > > > Kai, do you have a chance to bump the Fedora maintainer? An update > > to the latest state would help our cause a lot. > > I am about to give the Fedora-maintainer a ping about this. Thanks! > >> until I manually upgraded to > >> mingw32-headers-2.0.999-0.13.trunk.20121016.fc19.noarch.rpm from > >> rawhide. F16 (which uses the mingw.org toolchain) should also be okay. > >> > >> Apply the patch, rm -r winsup/mingw/ winsup/w32api/ winsup/utils/mingw, > >> run autoconf in winsup/utils, then configure and build. Tested so far > >> with CVS HEAD on Cygwin and Fedora 17 (with the aforementioned issue) > >> with our new w32api and the i686-w64-mingw32 toolchain; I have NOT yet > >> tested the resulting cygwin1.dll. > > > > Just FYI, there's a branch in sourceware called cygwin-64bit-branch. > > It contains all of Cygwin but omits the winsup/mingw and winsup/utils > > dir already. > > > > The idea of the branch is to collect all changes required to make Cygwin > > 64 bit work, while keeping the trunk intact for normal releases for the > > time being. Since we would like to keep Cygwin working on 32 bit, > > cygwin-64bit-branch is supposed to make sure that Cygwin still builds on > > 32 bit as well. > > > > I had a brief look into the patch but didn't test it yet. It looks good, > > but it misses out on one important thing: In contrast to Kai's patch, it > > does not test for the target CPU, so these patches don't allow to build > > with --target=x86_64-pc-cygwin. > > Hmm, where do I check --target option? I use host-triplet for > detecting cpu's architecture name. See in utils/configure.in file. Oh, I missed that. You should test the target CPU, not the host CPU. The winsup/cygwin/configure.in tests (and always did) the target CPU, too. Cygwin is a target lib and the utils are supposed to run on thei target. At least I think so. The difference between host and target is a bit academic in case of building the Cygwin DLL. But I think we should keep up with the scheme. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat