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
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
On Oct 19 11:33, Yaakov (Cygwin/X) wrote:
> 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.
Thanks!
> > 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.
That's nice, but... I'm not yet sure how *exactly* this should look like.
I don't know if you can just include the required cygwin headers without
trouble, for instance. Also, the 32 and the 64 bit version of the
cyglsa DLL belong together into a single 32 bit release. This requires
to have both mingw compilers installed to create a 32 bit Cygwin
release. Should configure fail if one of them can't be found? Or
should it just warn? Such a warning is easily missed. I think we
should discuss this first.
At one point we will also have to decide if the 64 bit cyglsa should be
built with 64 bit Cygwin...
> > 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.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
