[patch]: Decouple cygwin building from in-tree mingw/w32api building

Corinna Vinschen corinna-cygwin@cygwin.com
Thu Oct 18 16:22:00 GMT 2012


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



More information about the Cygwin-patches mailing list