Re: Fwd: Re: [patch]: Decouple cygwin building from in-tree mingw/w32api building
On Oct 23 17:48, Christopher Faylor wrote: On Tue, Oct 23, 2012 at 09:50:10PM +0100, Keith Marshall wrote: And just like Earnie's, the response he requested from me also bounced. Forwarded copy below: Original Message Subject: Re: [patch]: Decouple cygwin building from in-tree mingw/w32api building Date: Tue, 23 Oct 2012 21:41:07 +0100 From: Keith Marshall ... Organization: MinGW Project To: Earnie Boyd ... CC: cygwin-patches... On 22/10/12 12:14, Earnie Boyd wrote: On Mon, Oct 22, 2012 at 12:09 AM, Christopher Faylor wrote: Earnie, we seem to be transitioning from the need to have a mingw/w32api in the source tree. What do you think about removing these directories from the depot and moving repo to sourceforge, or some other place? In anticipation of this event I've already copied the source. I would like to leave the code in winsup until the end of the year if that timeline is fine with Keith. Fine by me; I also have my Mercurial clones of both repositories, from the time when we abandoned them in favour of our own git repository on SourceForge. You've got a home for as long as you like on sourceware.org but I was thinking that it might be advantageous for mingw to move anyway. Thanks and we agree that the move is advantageous. If it helps, I can provide tar copies of the directories from sourceware. I don't think I need them; Keith what do you think? We've moved on, anyway; any such copies would surely be obsolete. I think it's pretty clear that we didn't know you had moved on. The last update to w32api was on 2012-08-10 and mingw was on 2012-08-06. A heads up would have been appreciated. Just to be sure: Does that mean we can simply remove the mingw and w32api dirs in the sourceware repo any time? Corinna
Re: [patch]: Decouple cygwin building from in-tree mingw/w32api building
On Mon, 2012-10-22 at 14:23 +0200, Corinna Vinschen wrote:
If the original patch with the aforementioned changes is ok with
everybody, I'd apply it asap and remove lsaauth/cyglsa64.dll,
lsaauth/make-64bit-version-with-mingw-w64.sh, and utils/mingw.
Revised patches for winsup/cygwin and winsup/utils attached; I'm going
to leave the AC_NO_EXECUTABLES part to you, as I'm not in a position to
test that. Before I apply these, are there special procedures for the
toplevel patch?
Yaakov
2012-10-24 Kai Tietz ktietz70@...
Yaakov Selkowitz yselkowitz@...
Corinna Vinschen corinna@...
* configure.in: Add check for MINGW_CXX. Remove libiconv check.
* configure: Regenerate.
* Makefile.in: Remove references to mingw and w32api directories.
Use MINGW_CXX instead of mingw script to build MINGW_BINS.
Check for libiconv with $CC --print-file-name.
* cygcheck.cc: Use relative include paths for Cygwin headers.
* path.cc: Ditto.
* strace.cc: Ditto
* mingw: Remove.
Index: Makefile.in
===
RCS file: /cvs/src/src/winsup/utils/Makefile.in,v
retrieving revision 1.101
diff -u -p -r1.101 Makefile.in
--- Makefile.in 19 Oct 2012 11:58:48 - 1.101
+++ Makefile.in 24 Oct 2012 09:20:16 -
@@ -40,15 +40,11 @@ include $(srcdir)/../Makefile.common
.NOEXPORT:
.PHONY: all install clean realclean warn_dumper warn_cygcheck_zlib
-ALL_LDLIBS := -lnetapi32 -ladvapi32
-ALL_LDFLAGS:= -static-libgcc -Wl,--enable-auto-import -B$(newlib_build)/libc -B$(w32api_lib) $(LDFLAGS) $(ALL_LDLIBS)
-ALL_DEP_LDLIBS := $(cygwin_build)/libcygwin.a ${patsubst -l%,\
-$(w32api_lib)/lib%.a,$(ALL_LDLIBS) -lkernel32 -luser32}
-
-MINGW_LIB:= $(mingw_build)/libmingw32.a
-MINGW_LDLIBS := $(ALL_LDLIBS) $(MINGW_LIB)
-MINGW_DEP_LDLIBS := $(ALL_DEP_LDLIBS) $(MINGW_LIB)
-MINGW_CXX:= ${srcdir}/mingw ${CXX} -I${updir}
+ALL_LDLIBS := -lnetapi32 -ladvapi32 -lkernel32 -luser32
+ALL_LDFLAGS:= -static-libgcc -Wl,--enable-auto-import -B$(newlib_build)/libc $(LDFLAGS) $(ALL_LDLIBS)
+ALL_DEP_LDLIBS := $(cygwin_build)/libcygwin.a
+
+MINGW_CXX := @MINGW_CXX@
# List all binaries to be linked in Cygwin mode. Each binary on this list
# must have a corresponding .o of the same name.
@@ -74,7 +70,8 @@ path-mount.o: path.cc
mount.exe: path-mount.o
# Provide any necessary per-target variable overrides.
-cygcheck.exe: MINGW_LDFLAGS += -B{w32api_lib} -lpsapi -lntdll -lmsvcrt
+cygcheck.exe: MINGW_CXXFLAGS += -idirafter $(cygwin_source)/include -idirafter $(newlib_source)/libc/include
+cygcheck.exe: MINGW_LDFLAGS += -lpsapi -lntdll
cygpath.exe: ALL_LDFLAGS += -lcygwin -luserenv -lntdll
cygpath.exe: CXXFLAGS += -fno-threadsafe-statics
ps.exe: ALL_LDFLAGS += -lcygwin -lpsapi -lntdll
@@ -83,21 +80,20 @@ strace.exe: MINGW_LDFLAGS += -lntdll
ldd.exe: ALL_LDFLAGS += -lpsapi
pldd.exe: ALL_LDFLAGS += -lpsapi
-ldh.exe: MINGW_LDLIBS :=
ldh.exe: MINGW_LDFLAGS := -nostdlib -lkernel32
# Check for dumper's requirements and enable it if found.
-LIBICONV := @libiconv@
+libiconv := ${shell $(CC) --print-file-name=libiconv.a}
libbfd := ${shell $(CC) -B$(bupdir2)/bfd/ --print-file-name=libbfd.a}
libintl := ${shell $(CC) -B$(bupdir2)/intl/ --print-file-name=libintl.a}
bfdlink := $(shell ${CC} -xc /dev/null -o /dev/null -c -B${bupdir2}/bfd/ -include bfd.h 21)
-build_dumper := ${shell test -r $(libbfd) -a -r $(libintl) -a -n $(LIBICONV) -a -z ${bfdlink} echo 1}
+build_dumper := ${shell test -r $(libbfd) -a -r $(libintl) -a -n $(libiconv) -a -z ${bfdlink} echo 1}
ifdef build_dumper
CYGWIN_BINS += dumper.exe
dumper.o module_info.o parse_pe.o: CXXFLAGS += -I$(bupdir2)/bfd -I$(updir1)/include
dumper.o parse_pe.o: dumper.h
dumper.exe: module_info.o parse_pe.o
-dumper.exe: ALL_LDFLAGS += ${libbfd} ${libintl} -L$(bupdir1)/libiberty $(LIBICONV) -liberty -lz
+dumper.exe: ALL_LDFLAGS += ${libbfd} ${libintl} -L$(bupdir1)/libiberty $(libiconv) -liberty -lz
else
all: warn_dumper
endif
@@ -105,7 +101,7 @@ endif
# Check for availability of a MinGW libz and enable for cygcheck.
libz:=${shell x=$$(${MINGW_CXX} --print-file-name=libz.a); cd $$(dirname $$x); dir=$$(pwd); case $$dir in *mingw*) echo $$dir/libz.a ;; esac}
ifdef libz
-zlib_h := -include ${patsubst %/lib/mingw/libz.a,%/include/zlib.h,${patsubst %/lib/libz.a,%/include/zlib.h,$(libz)}}
+zlib_h := -include ${patsubst %/lib/libz.a,%/include/zlib.h,$(libz)}
zconf_h := ${patsubst %/zlib.h,%/zconf.h,$(zlib_h)}
dump_setup.o: MINGW_CXXFLAGS += $(zconf_h) $(zlib_h)
cygcheck.exe: MINGW_LDFLAGS += $(libz)
@@ -160,7 +156,7 @@ endif
# note: how to compile a Cygwin object is covered by the pattern rule in Makefile.common
# these dependencies ensure that the required in-tree libs are built first
-$(MINGW_BINS): $(MINGW_DEP_LDLIBS)
+$(MINGW_BINS): $(ALL_DEP_LDLIBS)
$(CYGWIN_BINS): $(ALL_DEP_LDLIBS)
clean:
@@ -179,9 +175,6 @@ install: all
$(cygwin_build)/libcygwin.a:
Re: [patch]: Decouple cygwin building from in-tree mingw/w32api building
On Oct 24 04:30, Yaakov (Cygwin/X) wrote: On Mon, 2012-10-22 at 14:23 +0200, Corinna Vinschen wrote: If the original patch with the aforementioned changes is ok with everybody, I'd apply it asap and remove lsaauth/cyglsa64.dll, lsaauth/make-64bit-version-with-mingw-w64.sh, and utils/mingw. Revised patches for winsup/cygwin and winsup/utils attached; I'm going to leave the AC_NO_EXECUTABLES part to you, as I'm not in a position to test that. Ok, I'll add them afterwards. Before I apply these, are there special procedures for the toplevel patch? Checking in toplevel patches requires global checkin rights. I can apply the toplevel patch when you applied the rest. Other than that, toplevel patches also have to be kept aligned with the gcc repo. I'll make sure to inform the gcc guys. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [patch]: Decouple cygwin building from in-tree mingw/w32api building
On Oct 24 11:50, Corinna Vinschen wrote: On Oct 24 04:30, Yaakov (Cygwin/X) wrote: On Mon, 2012-10-22 at 14:23 +0200, Corinna Vinschen wrote: If the original patch with the aforementioned changes is ok with everybody, I'd apply it asap and remove lsaauth/cyglsa64.dll, lsaauth/make-64bit-version-with-mingw-w64.sh, and utils/mingw. Revised patches for winsup/cygwin and winsup/utils attached; I'm going to leave the AC_NO_EXECUTABLES part to you, as I'm not in a position to test that. Ok, I'll add them afterwards. Before I apply these, are there special procedures for the toplevel patch? Checking in toplevel patches requires global checkin rights. I can apply the toplevel patch when you applied the rest. Other than that, toplevel patches also have to be kept aligned with the gcc repo. I'll make sure to inform the gcc guys. Oh btw., if that wasn't clear: Please apply all but toplevel. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [patch]: Decouple cygwin building from in-tree mingw/w32api building
On Wed, 2012-10-24 at 12:01 +0200, Corinna Vinschen wrote: Checking in toplevel patches requires global checkin rights. I can apply the toplevel patch when you applied the rest. Other than that, toplevel patches also have to be kept aligned with the gcc repo. I'll make sure to inform the gcc guys. Oh btw., if that wasn't clear: Please apply all but toplevel. Done. While you're at it, perhaps you could bump this patch as well: http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01578.html Yaakov
Re: [patch]: Decouple cygwin building from in-tree mingw/w32api building
On Mon, Oct 22, 2012 at 10:29:13AM +0200, Corinna Vinschen wrote: On Oct 22 00:09, Christopher Faylor wrote: Yeah, since the changes to the configury separate Cygwin from mingw and w32api, staying in src/winsup is no problem at all. I always thought mingw is part of the src tree for gcc bootstrap reasons. winsup is not part of the gcc source tree in SVN. So, if it is necessary for bootstrapping it must have to be pulled in separately anyway. And, if we're talking about moving cygwin entirely to w64api then I don't see how it could be part of the gcc bootstrap. But, even if it was, I don't see why we would have to limit our directory layout for another project. cgf
Re: [patch]: Decouple cygwin building from in-tree mingw/w32api building
Hi Yaakov,
On Oct 21 16:39, Yaakov (Cygwin/X) wrote:
On Fri, 2012-10-19 at 11:33 -0500, Yaakov (Cygwin/X) wrote:
I'll include those changes and post a new patch then.
Revised patches for toplevel, winsup, winsup/cygwin, winsup/lsaauth, and
winsup/utils attached. Tested on Cygwin and F17 with mingw32-headers
from rawhide.
The patch looks pretty well for i686. The only nit I have left is that
the DLL_IMPORTS expression should just use ${shell ...} rather than `...`:
DLL_IMPORTS:=${shell $(CC) -print-file-name=w32api/libkernel32.a} ${shell
$(CC) -print-file-name=w32api/libntdll.a}
The lsaauth changes still give me a tiny little bit of headache, but
it's certainly an improvement over the current state, so we take it
as is and improve it when the time is ripe.
I also tested the patch in the 64 bit branch with a 64 bit compiler,
which uncovered two problems which were not visible before:
- AC_NO_EXECUTABLES is missing in doc/configure.in, lsaauth/configure.in
and utils/configure.in. Without this, configure tries to link with
the target compiler, but that's not possible during bootstrap.
- OTOH, AC_NO_EXECUTABLES disables any linkage tests, so the LIBICONV
test in utils/configure.in has to be replaced or go away. In my below
patch I opted for go away. I just replaced it by -liconv in
Makefile.in:
Index: Makefile.in
[...]
# Check for dumper's requirements and enable it if found.
-LIBICONV := @libiconv@
libbfd := ${shell $(CC) -B$(bupdir2)/bfd/ --print-file-name=libbfd.a}
libintl := ${shell $(CC) -B$(bupdir2)/intl/ --print-file-name=libintl.a}
bfdlink := $(shell ${CC} -xc /dev/null -o /dev/null -c
-B${bupdir2}/bfd/ -include bfd.h 21)
-build_dumper := ${shell test -r $(libbfd) -a -r $(libintl) -a -n $(LIBICONV)
-a -z ${bfdlink} echo 1}
+build_dumper := ${shell test -r $(libbfd) -a -r $(libintl) -a -z ${bfdlink}
echo 1}
ifdef build_dumper
CYGWIN_BINS += dumper.exe
dumper.o module_info.o parse_pe.o: CXXFLAGS += -I$(bupdir2)/bfd
-I$(updir1)/include
dumper.o parse_pe.o: dumper.h
dumper.exe: module_info.o parse_pe.o
-dumper.exe: ALL_LDFLAGS += ${libbfd} ${libintl} -L$(bupdir1)/libiberty
$(LIBICONV) -liberty -lz
+dumper.exe: ALL_LDFLAGS += ${libbfd} ${libintl} -L$(bupdir1)/libiberty -liconv
-liberty -lz
else
all: warn_dumper
endif
[...]
warn_dumper:
@echo '*** Not building dumper.exe since some required libraries or'
@echo '*** or headers are missing. Potential candidates are:'
- @echo '*** bfd.h, libbfd.a, libiconv.a, or libintl.a'
+ @echo '*** bfd.h, libbfd.a, or libintl.a'
@echo '*** If you need this program, check out the naked-bfd and
naked-intl'
@echo '*** sources from sourceware.org. Then, configure and build
these'
@echo '*** libraries. Otherwise, you can safely ignore this warning.'
Index: configure.in
[...]
AC_ARG_PROGRAM
-AC_CHECK_LIB(iconv, libiconv, libiconv=-liconv)
-AC_SUBST(libiconv)
-
INSTALL=/bin/sh `cd $srcdir/../..; echo $(pwd)/install-sh -c`
[...]
If the original patch with the aforementioned changes is ok with
everybody, I'd apply it asap and remove lsaauth/cyglsa64.dll,
lsaauth/make-64bit-version-with-mingw-w64.sh, and utils/mingw.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [patch]: Decouple cygwin building from in-tree mingw/w32api building
On Oct 19 20:46, Corinna Vinschen wrote: On Oct 19 11:33, Yaakov (Cygwin/X) wrote: On Fri, 2012-10-19 at 11:21 +0200, Corinna Vinschen wrote: Other than that, I think it's good to go in after the 1.7.17 release. I'll try to do the release at some point between now and Monday. I'll include those changes and post a new patch then. On second thought... considering that w32api is now Mingw64 based, and considering that building Cygwin with this Mingw64 built w32api works fine... what do you guys think about a once and for all approach? Is it really necessary to keep supporting a build against the old w32api? What does that buy us apart from added complexity? Doesn't that also mean we have to test our builds against both w32api versions as long as we support it? I, for one, have no real interest to do so. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [patch]: Decouple cygwin building from in-tree mingw/w32api building
On Sun, 2012-10-21 at 13:33 +0200, Corinna Vinschen wrote:
On second thought... considering that w32api is now Mingw64 based, and
considering that building Cygwin with this Mingw64 built w32api works
fine... what do you guys think about a once and for all approach? Is
it really necessary to keep supporting a build against the old w32api?
What does that buy us apart from added complexity? Doesn't that also
mean we have to test our builds against both w32api versions as long as
we support it? I, for one, have no real interest to do so.
AFAICS the momentum has been moving towards mingw-w64 since Fedora
switched for F17; I'm seeing more and more packages which compile with
mingw-w64 but not with mingw.org's toolchain. Now that we've moved to a
mingw-w64-based w32api, F16 (the last release to use mingw.org) will be
EOL soon enough (one month after F18), and mingw-w64 is absolutely
required for adding x64 support, I agree that this would be a good time
to just switch and be done with it. (Does the same apply to setup.exe?)
That does raise a related, but off-topic here, question as to whether we
need to continue supporting both toolchains in the distro, or if we
should just drop mingw-* and possibly rename mingw64-{i686,x86_64} to
mingw32- and mingw64- as Fedora has done. But I imagine that may be a
bit contentious for some, so let's discuss that elsewhere.
Yaakov
Re: [patch]: Decouple cygwin building from in-tree mingw/w32api building
On Sun, Oct 21, 2012 at 01:33:20PM +0200, Corinna Vinschen wrote: On Oct 19 20:46, Corinna Vinschen wrote: On Oct 19 11:33, Yaakov (Cygwin/X) wrote: On Fri, 2012-10-19 at 11:21 +0200, Corinna Vinschen wrote: Other than that, I think it's good to go in after the 1.7.17 release. I'll try to do the release at some point between now and Monday. I'll include those changes and post a new patch then. On second thought... considering that w32api is now Mingw64 based, and considering that building Cygwin with this Mingw64 built w32api works fine... what do you guys think about a once and for all approach? Is it really necessary to keep supporting a build against the old w32api? What does that buy us apart from added complexity? Doesn't that also mean we have to test our builds against both w32api versions as long as we support it? I, for one, have no real interest to do so. I had exactly the same thought. I'm in favor of just doing the switchover. That said, is it time to ask the mingw.org stuff to relocate their CVS repo? I could tar up the affected CVS directories for them if so. cgf
Re: [patch]: Decouple cygwin building from in-tree mingw/w32api building
On Sun, Oct 21, 2012 at 01:32:41PM -0500, Yaakov (Cygwin/X) wrote: On Sun, 2012-10-21 at 13:10 -0400, Christopher Faylor wrote: That said, is it time to ask the mingw.org stuff to relocate their CVS repo? I could tar up the affected CVS directories for them if so. What about some CVSROOT/modules magic to exclude winsup/mingw and winsup/w32api from a Cygwin checkout? 1) change the existing cygwin module to naked-cygwin; 2) add a new cygwin module with -a src-support naked-cygwin naked-newlib naked-include; 3) change the directions on cvs.html to cvs co cygwin instead of cvs co winsup for new checkouts; 4) devs with existing checkouts could just rm -fr winsup/mingw winsup/w32api if they so choose (but with the patch, they won't be used anymore even if present). As mingw.org already treats winsup/mingw and winsup/w32api as separate repos[1], that should do the trick for us without forcing them to move. Given our long-standing cooperation until now, I think it's the least we could do. I wasn't trying to punish anyone. I actually thought that they probably hadn't moved already mainly out of courtesy to us. I vaguely recall some rumbling about this in the past. I've cc'ed Earnie to see how he feels about it. Earnie, we seem to be transitioning from the need to have a mingw/w32api in the source tree. What do you think about removing these directories from the depot and moving repo to sourceforge, or some other place? You've got a home for as long as you like on sourceware.org but I was thinking that it might be advantageous for mingw to move anyway. If it helps, I can provide tar copies of the directories from sourceware. Alternately, I can also provide you with a top-level directory at sourceware.org if that is preferable. cgf
Re: [patch]: Decouple cygwin building from in-tree mingw/w32api building
On Oct 18 12:20, Yaakov (Cygwin/X) wrote: On Thu, 2012-10-18 at 10:34 +0200, Corinna Vinschen wrote: Any problem to move mingw64-i686-zlib into the distro? None; should I also move the other setup.exe prerequisites for i686-w64-mingw32? Would you also like x86_64 versions of any of those? If it's not asked too much, sure on both accounts! 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. This particular change doesn't really have to do with 32-vs-64-bit, but with switching from mingw.org's w32api/runtime to mingw-w64's. (Obviously, I'm testing this with i686.) So, once thoroughly tested, it could go straight into HEAD. Indeed. 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. That's easy enough to fix. - 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, isn't it? Same goes for -isystem $$s/winsup/include. Yep. Revised patch attached. Thanks. Looks good, I have problems with this patch. The theory is that cygwin will continue to co-exist with mingw and w32api for a while, but cygwin does not build or use mingw and w32api. However, winsup/configure.in adds mingw and w32api subdirs to SUBDIRS based on the mere existence of the dirs. If we want to make Cygwin independent of mingw/w32api and vice versa, I'd suggest the following patch to winsup/configure.in instead: Index: winsup/configure.in === RCS file: /cvs/src/src/winsup/configure.in,v retrieving revision 1.33 diff -u -p -r1.33 configure.in --- winsup/configure.in 29 Jan 2011 06:41:28 - 1.33 +++ winsup/configure.in 19 Oct 2012 08:34:36 - @@ -32,33 +32,17 @@ case $target in if ! test -d $srcdir/cygwin; then AC_MSG_ERROR(No cygwin dir. Can't build Cygwin. Exiting...) fi -AC_CONFIG_SUBDIRS(cygwin) +AC_CONFIG_SUBDIRS(cygwin cygserver lsaauth utils doc) INSTALL_LICENSE=install-license ;; *mingw*) if ! test -d $srcdir/mingw; then AC_MSG_ERROR(No mingw dir. Can't build Mingw. Exiting...) fi -;; -esac - -if test -d $srcdir/mingw; then - AC_CONFIG_SUBDIRS(mingw) -fi -AC_CONFIG_SUBDIRS(w32api cygserver) - -case $with_cross_host in - |*cygwin*) -# if test -d $srcdir/bz2lib; then -# AC_CONFIG_SUBDIRS(bz2lib) -# fi -# if test -d $srcdir/zlib; then -# AC_CONFIG_SUBDIRS(zlib) -# fi -if test -d $srcdir/lsaauth; then - AC_CONFIG_SUBDIRS(lsaauth) +AC_CONFIG_SUBDIRS(mingw) +if test -d $srcdir/w32api; then + AC_CONFIG_SUBDIRS(w32api) fi -AC_CONFIG_SUBDIRS(utils doc) ;; esac This builds cygwin, cygserver, lsaauth, utils and doc dirs if the target is Cygwin, mingw and w32api otherwise. Index: winsup/lsaauth/Makefile.in === RCS file: /cvs/src/src/winsup/lsaauth/Makefile.in,v retrieving revision 1.6 diff -u -p -r1.6 Makefile.in --- winsup/lsaauth/Makefile.in29 May 2012 12:46:01 - 1.6 +++ winsup/lsaauth/Makefile.in18 Oct 2012 17:13:54 - @@ -33,7 +33,7 @@ CFLAGS := @CFLAGS@ include $(srcdir)/../Makefile.common -WIN32_INCLUDES := -I. -I$(srcdir) $(w32api_include) $(w32api_include)/ddk +WIN32_INCLUDES := -I. -I$(srcdir) WIN32_CFLAGS:= $(CFLAGS) $(WIN32_COMMON) $(WIN32_INCLUDES) WIN32_LDFLAGS:= $(CFLAGS) $(WIN32_COMMON) -nostdlib -Wl,-shared Just as a note for the future, we don't have to fix that immediately: Given that the lsaauth modules don't call any Cygwin function but rather only use a few Cygwin datastructure, and given that we now require a mingw compiler to build the native utils anyway, I'm wondering if we shouldn't simply require the x86 and x86_64 targeting mingw compilers to build the lsaauth modules as well. If we do that, we could already build the 32 and the 64 bit versions of the lsaauth module today, right from the Makefile. That sounds
Re: [patch]: Decouple cygwin building from in-tree mingw/w32api building
On Oct 19 11:21, Corinna Vinschen wrote: Thanks. Looks good, I have problems with this patch. That should have been: Thanks. Looks good, I just have a few small problems with this patch. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [patch]: Decouple cygwin building from in-tree mingw/w32api building
On Fri, 2012-10-19 at 11:21 +0200, Corinna Vinschen wrote:
On Oct 18 12:20, Yaakov (Cygwin/X) wrote:
None; should I also move the other setup.exe prerequisites for
i686-w64-mingw32? Would you also like x86_64 versions of any of those?
If it's not asked too much, sure on both accounts!
Done.
The theory is that cygwin will continue to co-exist with mingw and
w32api for a while, but cygwin does not build or use mingw and w32api.
However, winsup/configure.in adds mingw and w32api subdirs to SUBDIRS
based on the mere existence of the dirs.
If we want to make Cygwin independent of mingw/w32api and vice versa,
I'd suggest the following patch to winsup/configure.in instead:
This builds cygwin, cygserver, lsaauth, utils and doc dirs
if the target is Cygwin, mingw and w32api otherwise.
I'll incorporate that into my next draft.
Just as a note for the future, we don't have to fix that immediately:
Given that the lsaauth modules don't call any Cygwin function but rather
only use a few Cygwin datastructure, and given that we now require a
mingw compiler to build the native utils anyway, I'm wondering if we
shouldn't simply require the x86 and x86_64 targeting mingw compilers to
build the lsaauth modules as well.
If we do that, we could already build the 32 and the 64 bit versions
of the lsaauth module today, right from the Makefile. That sounds
like a much better solution than the make-64bit-version-with-mingw-w64.sh
script and keeping the 64 bit DLL as a binary blob in the repo, doesn't
it?
Agreed, I'll add that too.
A very minor nit: Personally I feel better if variables are braced in
such a scenario. From my POV it's also easier readable:
AC_CHECK_PROGS(MINGW_CXX, ${target_cpu}-w64-mingw32-g++
${target_cpu}-pc-mingw32-g++)
Fine.
Other than that, I think it's good to go in after the 1.7.17 release.
I'll try to do the release at some point between now and Monday.
I'll include those changes and post a new patch then.
Yaakov
Re: [patch]: Decouple cygwin building from in-tree mingw/w32api building
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? 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. 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. 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 - 1.174 +++ configure.ac 18 Oct 2012 05:50:52 - @@ -2801,7 +2801,7 @@ case $target_configdirs in * --with-newlib *) case $target in *-cygwin*) - 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, isn't it? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [patch]: Decouple cygwin building from in-tree mingw/w32api building
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? 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. 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. Regards, Kai
Re: [patch]: Decouple cygwin building from in-tree mingw/w32api building
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
Re: [patch]: Decouple cygwin building from in-tree mingw/w32api building
On Thu, 2012-10-18 at 10:34 +0200, Corinna Vinschen wrote:
Any problem to move mingw64-i686-zlib into the distro?
None; should I also move the other setup.exe prerequisites for
i686-w64-mingw32? Would you also like x86_64 versions of any of those?
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.
This particular change doesn't really have to do with 32-vs-64-bit, but
with switching from mingw.org's w32api/runtime to mingw-w64's.
(Obviously, I'm testing this with i686.) So, once thoroughly tested, it
could go straight into HEAD.
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.
That's easy enough to fix.
- 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,
isn't it?
Same goes for -isystem $$s/winsup/include.
Revised patch attached.
Yaakov
Index: configure
===
RCS file: /cvs/src/src/configure,v
retrieving revision 1.430
diff -u -p -r1.430 configure
--- configure 29 Sep 2012 15:35:52 - 1.430
+++ configure 18 Oct 2012 17:13:48 -
@@ -7207,7 +7207,7 @@ case $target_configdirs in
* --with-newlib *)
case $target in
*-cygwin*)
- 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/cygwin -isystem $$s/winsup/cygwin/include'
;;
esac
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 - 1.174
+++ configure.ac 18 Oct 2012 17:13:49 -
@@ -2801,7 +2801,7 @@ case $target_configdirs in
* --with-newlib *)
case $target in
*-cygwin*)
- 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/cygwin -isystem $$s/winsup/cygwin/include'
;;
esac
Index: winsup/Makefile.common
===
RCS file: /cvs/src/src/winsup/Makefile.common,v
retrieving revision 1.59
diff -u -p -r1.59 Makefile.common
--- winsup/Makefile.common 30 Jul 2012 04:43:21 - 1.59
+++ winsup/Makefile.common 18 Oct 2012 17:13:54 -
@@ -72,38 +72,20 @@ ifeq (,${findstring $(cygwin_source)/inc
cygwin_include:=-I$(cygwin_source)/include
endif
-# Try to determine what directories are available in winsup.
-# Attempt to properly detect missing mingw or w32api and adjust command
-# line parameters appropriately
-
-# nostdinc:=${shell [ -d $(updir)/w32api ] echo -nostdinc}
-# ifneq (,$(nostdinc))
-nostdincxx:=-nostdinc++
-# ifeq (,${findstring $(w32api_source),$(CFLAGS) $(CXXFLAGS) $(CXX) $(CC)})
-w32api_include:=-I$(w32api_source)/include
-# endif
-# endif
-
-mingw_include:=${shell [ -d $(mingw_source)/include ] echo -I$(mingw_source)/include}
-ifneq (,$(mingw_include))
nostdlib:=-nostdlib
-else
-nostdlib:=
-endif
ifeq (,${nostdlib})
nostdinc:=
endif
-INCLUDES:=-I. $(cygwin_include) -I$(cygwin_source) $(newlib_include) $(w32api_include)
+INCLUDES:=-I. $(cygwin_include) -I$(cygwin_source) $(newlib_include)
ifdef CONFIG_DIR
INCLUDES+=-I$(CONFIG_DIR)
endif
-MINGW_INCLUDES:=${mingw_include} $(w32api_include)
-MINGW_CFLAGS:=-mno-cygwin $(MINGW_INCLUDES)
-MINGW_CXXFLAGS:=${filter-out $(newlib_source)/%,$(CXXFLAGS)} -mno-cygwin $(MINGW_INCLUDES)
-MINGW_LDFLAGS:=-L${mingw_build} -L${mingw_build}/mingwex
+MINGW_LDFLAGS:=-static
+MINGW_CFLAGS:=
+MINGW_CXXFLAGS:=
GCC_DEFAULT_OPTIONS:=$(CFLAGS_COMMON) $(CFLAGS_CONFIG) $(INCLUDES)
@@ -134,7
Re: [patch]: Decouple cygwin building from in-tree mingw/w32api building
Hi Kai, On Oct 17 18:13, Kai Tietz wrote: Hello everybody, This patch modifies the bits of build-process so that cygwin and mingw building is decoupled from each other. Additionally the patch decouples cygwin's build from the w32api of mingw.org. By this change it is now possible to build cygwin (and utilities) with mingw.org's and mingw-w64's psdk and compilers. Later are necessary to build cygwin's native utils, which have not to depend on cygwin1.dll. These changes are also necessary for having 64-bit build support in future. By this reason the mingw-script in utils/ had to learn about the host's architecture and about how to search for an installed mingw-toolchain for given architecture. As Corinna told me that cygwin wants to use in question the -w64- mingw-environment, this script is searching first for -w64- based toolchain. On second attempt it searches for any mingw triplet for given architecture. obviously I know your patch since I tested it already (and even accidentally checked in parts of it into the 64bit branch), so I know it works. However, your patch submission is broken due to wrong line-breaks. Can you please resend the patch, if you don't trust your MUA, maybe better as text/plain attachment? Oh and, btw., in the Cygwin ChangeLogs we tend to use up to 80 chars per line. That's not a big problem, I just want you to know for future patch submissions. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [patch]: Decouple cygwin building from in-tree mingw/w32api building
On Oct 17 12:44, Christopher Faylor wrote:
On Wed, Oct 17, 2012 at 06:13:18PM +0200, Kai Tietz wrote:
-[ $dir = '/' ] dir=''
+[ $dir = '/' ] dir='';
No need for a semicolon here.
I have other comments but I wonder if it would just be best to scrap this
script and assume that there is a mingw compiler installed. When I first
wrote this script there was no mingw compiler in the distro. Now there
is. So I think we should just make that a requirement for building.
When I told Kai what to do I was always grumpy about requiring a
non-cygwin compiler to build parts of Cygwin. That's why this
mingw script allows to build with a mingw64, a mingw32 or a cygwin
compiler.
But it really looks like the easiest solution is to require a mingw
compiler since the mingw headers and libs have to be installed anyway.
That just requires to change configure.in to test for a
${cpu}-w64-mingw32 compiler and to define MINGW_CXX accordingly, afaics.
Then, no more head standing is required.
Index: winsup/Makefile.common
===
RCS file: /cvs/src/src/winsup/Makefile.common,v
retrieving revision 1.59
diff -p -u -3 -r1.59 Makefile.common
--- winsup/Makefile.common 30 Jul 2012 04:43:21 - 1.59
+++ winsup/Makefile.common 17 Oct 2012 15:21:32 -
Can we just get rid of this as well? That's what I did in my now-unneeded
revamp of the configury in the cygwin git repository.
I think I'd rather just move everything into winsup, cygserver, utils and
not bother with this common stuff.
But it's still a nice way to have certain definitions only once.
The BSD build systems use something similar.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
