[patch]: Decouple cygwin building from in-tree mingw/w32api building
Thu Oct 18 08:34:00 GMT 2012
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?
> 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.
> 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
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
> Index: configure.ac
> RCS file: /cvs/src/src/configure.ac,v
> retrieving revision 1.174
> diff -u -p -r1.174 configure.ac
> --- configure.ac 29 Sep 2012 15:35:53 -0000 1.174
> +++ configure.ac 18 Oct 2012 05:50:52 -0000
> @@ -2801,7 +2801,7 @@ case " $target_configdirs " in
> *" --with-newlib "*)
> case "$target" in
> - FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -L$$r/$(TARGET_SUBDIR)/winsup -L$$r/$(TARGET_SUBDIR)/winsup/cygwin -L$$r/$(TARGET_SUBDIR)/winsup/w32api/lib -isystem $$s/winsup/include -isystem $$s/winsup/cygwin/include -isystem $$s/winsup/w32api/include'
> + FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -L$$r/$(TARGET_SUBDIR)/winsup -L$$r/$(TARGET_SUBDIR)/winsup/cygwin -isystem $$s/winsup/include -isystem $$s/winsup/cygwin/include'
This change reminds me. Why on earth do we have a
-L$$r/$(TARGET_SUBDIR)/winsup in there? How old is that? We don't
have any libs in the winsup dir anyway, so we should remove that,
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
More information about the Cygwin-patches