From: Chris S. <ir0...@gm...> - 2006-09-09 11:22:50
|
I see the cross compiler stuff seems to be causing several users some grief (which I assume is why Keith created the CVS build of runtime). Should I create a full release of runtime or are we good with the CVS release fore now? Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org |
From: Michael G. <mg...@te...> - 2006-09-09 13:31:16
|
> I see the cross compiler stuff seems to be causing several users some > grief (which I assume is why Keith created the CVS build of runtime). > Should I create a full release of runtime or are we good with the CVS > release fore now? Given that there also was the math.h error I'm for a new release. Is there some documentation as to how the releases of runtime and w32api are created out of the winsup cvs ? A pointer would be fine. Best, Michael |
From: Keith M. <kei...@us...> - 2006-09-09 13:33:08
|
On Saturday 09 September 2006 12:22 pm, Chris Sutcliffe wrote: > I see the cross compiler stuff seems to be causing several users some > grief (which I assume is why Keith created the CVS build of runtime). > Should I create a full release of runtime or are we good with the CVS > release fore now? I don't have any strong feeling either way. I didn't touch the prebuilt binary at all, so a new release now would merit no more than a patch level increment -- i.e. it would become 3.10.1. All I did change was the source tarball, replacing the broken aclocal.m4 and configure.in files with the newer CVS versions, *including* the patch I proposed last week, and regenerated configure. BTW, I've proven that patch for MinGW only, and haven't yet committed it. I asked if it might break anything for Cygwin, but have not received any reply from their developers. Maybe I should just check it in anyway, and see if they scream? I'd like to get the unnecessary cruft out of the CVS copies, before we publish, if we do decide to go for 3.10.1. Regards, Keith. |
From: Keith M. <kei...@us...> - 2006-09-09 16:10:26
|
On Saturday 09 September 2006 2:30 pm, Michael Gerdau wrote: > > I see the cross compiler stuff seems to be causing several users some > > grief (which I assume is why Keith created the CVS build of runtime). > > Should I create a full release of runtime or are we good with the CVS > > release fore now? > > Given that there also was the math.h error I'm for a new release. Oops. I didn't capture the math.h patch into that patched tarball I posted; I based it on the existing tarball, rather than a CVS snapshot, and only patched the aclocal.m4 and configure.in files, and regenerated configure. If we do release 3.10.1 now, it should be based on a current CVS snapshot. > Is there some documentation as to how the releases of runtime and > w32api are created out of the winsup cvs ? The normal way would be to do `./configure && make && make dist' in an up-to-date CVS working copy, which should create both the source and binary release tarballs. Unfortunately, mingw-runtime CVS is badly set up, for as it currently is, the `make' phase requires a working CVS copy of the w32api to also be present, in the correct relative location; it cannot use the w32api headers from an already installed working compiler. IMHO, this is wrong; it should be fixed, so that mingw-runtime can be configured as a self contained CVS module. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2006-09-11 12:15:34
|
Quoting Keith Marshall <kei...@us...>: > > The normal way would be to do `./configure && make && make dist' in an > up-to-date CVS working copy, which should create both the source and > binary release tarballs. Unfortunately, mingw-runtime CVS is badly set > up, for as it currently is, the `make' phase requires a working CVS copy > of the w32api to also be present, in the correct relative location; it > cannot use the w32api headers from an already installed working compiler. > IMHO, this is wrong; it should be fixed, so that mingw-runtime can be > configured as a self contained CVS module. > There is a W32API_INCLUDE variable in the runtime Makefile.in so that if you set its value during the make process it overrides what configure set it to. This probably needs work in the configure.ac to provide m4 logic to look for w32api.h file in the given include path. Earnie Boyd http://shop.siebunlimited.com |
From: Chris S. <ir0...@gm...> - 2006-09-10 11:03:47
|
> > >I see the cross compiler stuff seems to be causing several users some > > >grief (which I assume is why Keith created the CVS build of runtime). > > >Should I create a full release of runtime or are we good with the CVS > > >release fore now? > > > > Given that there also was the math.h error I'm for a new release. > > Oops. I didn't capture the math.h patch into that patched tarball I > posted; I based it on the existing tarball, rather than a CVS snapshot, > and only patched the aclocal.m4 and configure.in files, and regenerated > configure. If we do release 3.10.1 now, it should be based on a current > CVS snapshot. Does your patch need to be applied to CVS, or are the patches Corina applied sufficient? > > Is there some documentation as to how the releases of runtime and > > w32api are created out of the winsup cvs ? > > The normal way would be to do `./configure && make && make dist' in an > up-to-date CVS working copy, which should create both the source and > binary release tarballs. Unfortunately, mingw-runtime CVS is badly set > up, for as it currently is, the `make' phase requires a working CVS copy > of the w32api to also be present, in the correct relative location; it > cannot use the w32api headers from an already installed working compiler. > IMHO, this is wrong; it should be fixed, so that mingw-runtime can be > configured as a self contained CVS module. I believe the concept behind using the winsup CVS supplied w32api headers was that someone should be able to build the runtime without having build the w32api first. Having said that, there is some cleanup needed to the Makefile.in files, since doing a 'make distclean' still leaves a lot of stuff behind, I just haven't had the time to sort it out. FWIW, here is the shell script I use to build runtime: #!/bin/sh if [ "$1" != "install" ] && [ "$1" != "dist" ]; then echo build.sh install/dist exit 1 fi HOST_TYPE=i386-pc-mingw32 PACKAGE=runtime PREFIX=/mingw ../../$PACKAGE/configure --build=$HOST_TYPE --host=$HOST_TYPE --target=$HOST_TYPE --prefix=$PREFIX make CFLAGS="-s -O3 -mtune=i686 -mno-cygwin" $1 Cheers! Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org |
From: Keith M. <kei...@us...> - 2006-09-10 15:06:01
|
On Sunday 10 September 2006 12:03 pm, Chris Sutcliffe wrote: > > ... If we do release 3.10.1 now, it should be based on a > > current CVS snapshot. > > Does your patch need to be applied to CVS, or are the patches Corina > applied sufficient? Corinna's patches are sufficient to make things work correctly. However, they do leave some pointless, and indeed confusing cruft, in aclocal.m4 and configure.in. IMO, this should be cleaned up, before we make a new release; my patch will do that, so on balance, I think it should be applied before we proceed; I've done that now. > > > Is there some documentation as to how the releases of runtime and > > > w32api are created out of the winsup cvs ? > > > > The normal way would be to do `./configure && make && make dist' in > > an up-to-date CVS working copy, which should create both the source > > and binary release tarballs. Unfortunately, mingw-runtime CVS is > > badly set up, for as it currently is, the `make' phase requires a > > working CVS copy of the w32api to also be present, in the correct > > relative location; it cannot use the w32api headers from an already > > installed working compiler. IMHO, this is wrong; it should be fixed, > > so that mingw-runtime can be configured as a self contained CVS > > module. > > I believe the concept behind using the winsup CVS supplied w32api > headers was that someone should be able to build the runtime without > having build the w32api first. The problem is not so much that the w32api headers are required, but the inflexible way in which the Makefile assumes it can locate them. What should happen is that configure checks for their presence, using AC_CHECK_HEADERS on windows.h say, and also provides an AC_ARG_WITH option, to allow me to specify an alternative location to the default. That way, configure can offer informative advice on how to proceed, if it can't find them, rather than just leaving make to blow up gracelessly. I'll have a look at doing that, if you wish. > Having said that, there is some > cleanup needed to the Makefile.in files, since doing a 'make > distclean' still leaves a lot of stuff behind, I just haven't had the > time to sort it out. Well, we really should sort that out, sooner rather than later, but it doesn't need to be a prerequisite for releasing 3.10.1. > FWIW, here is the shell script I use to build runtime: > > ... > > HOST_TYPE=i386-pc-mingw32 > PACKAGE=runtime > PREFIX=/mingw > > ../../$PACKAGE/configure --build=$HOST_TYPE --host=$HOST_TYPE > --target=$HOST_TYPE --prefix=$PREFIX > make CFLAGS="-s -O3 -mtune=i686 -mno-cygwin" $1 I have some comments on this:-- 1) Does that `PREFIX=/mingw' relate to an MSYS path? If so, does it get resolved back to a native path somewhere during the build? Does it matter? 2) Specifying `HOST_TYPE=i386-pc-mingw32' leads to the expectation that you are building a generic library, which will support `i386' and later host platforms, yet `-mtune=i686' allows the compiler to emit instructions which may not be supported on `i386'..`i586' -- this would actually be a build for an `i686-pc-mingw32' host, not `i386-pc-mingw32'. We should maintain appropriate consistency here. 3) You shouldn't need to specify the `--target=...' option, when building runtime or API libraries; that applies specifically to tools which themselves emit code, i.e. the compiler itself, and has no meaning in the context of libraries. 4) Use of the `-mno-cygwin' flag is required only if your build platform is `ix86-pc-cygwin', so your configure command should resolve to something like `.../configure --build=i686-pc-cygwin --host=i686-pc-mingw32 ...' which is the standard way to invoke a cross-compiler. In fact `-mno-cygwin' is a Cygwin kludge to invoke a cygwin-x-mingw32 cross-compiler, without requiring the cross-tools to be properly named; If you are not using Cygwin, then you do not need `-mno-cygwin'. Indeed, Michael and I would be using `.../configure --build=i686-pc-linux --host=i686-pc-mingw32 ...' because we do have properly named linux-x-mingw32 tools, and this should suffice to correctly cross-compile the libraries; (FWIW, I have *never* found a need for the `-mno-cygwin' switch in any build, because I'm either on GNU/Linux or MSYS, and so have little need for Cygwin kludges). Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2006-09-10 22:48:14
|
> 1) Does that `PREFIX=/mingw' relate to an MSYS path? If so, does it get > resolved back to a native path somewhere during the build? Does it > matter? /mingw is the MSYS mount point for my MinGW directory. I've been using this script for all the releases I've created, and since no one has complained I assume it's OK. > 4) Use of the `-mno-cygwin' flag is required only if your build platform > is `ix86-pc-cygwin', so your configure command should resolve to > something like > > `.../configure --build=i686-pc-cygwin --host=i686-pc-mingw32 ...' > > which is the standard way to invoke a cross-compiler. In fact > `-mno-cygwin' is a Cygwin kludge to invoke a cygwin-x-mingw32 > cross-compiler, without requiring the cross-tools to be properly named; > If you are not using Cygwin, then you do not need `-mno-cygwin'. Indeed, > Michael and I would be using > > `.../configure --build=i686-pc-linux --host=i686-pc-mingw32 ...' > > because we do have properly named linux-x-mingw32 tools, and this should > suffice to correctly cross-compile the libraries; (FWIW, I have *never* > found a need for the `-mno-cygwin' switch in any build, because I'm > either on GNU/Linux or MSYS, and so have little need for Cygwin kludges). At one point I was using Cygwin as opposed to Msys for a *nix environment under Windows. In order to have a script that played nicely under both MSys and Cygwin, I added the --mno-cygwin flag, since under Cygwin, as you pointed out, it invokes the MinGW toolchain, and under MSys it has no effect. Cheers! Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org |
From: Earnie B. <ea...@us...> - 2006-09-11 12:02:27
|
Quoting Keith Marshall <kei...@us...>: > > BTW, I've proven that patch for MinGW only, and haven't yet committed it. > I asked if it might break anything for Cygwin, but have not received any > reply from their developers. Maybe I should just check it in anyway, and > see if they scream? I'd like to get the unnecessary cruft out of the CVS > copies, before we publish, if we do decide to go for 3.10.1. > The surest way to find that out is to commit the patch. You'll know in a few hours if it breaks a Cygwin build. Earnie Boyd http://shop.siebunlimited.com |
From: Christopher F. <me...@cg...> - 2006-09-11 14:00:29
|
On Mon, Sep 11, 2006 at 08:02:18AM -0400, Earnie Boyd wrote: >Quoting Keith Marshall <kei...@us...>: >>BTW, I've proven that patch for MinGW only, and haven't yet committed >>it. I asked if it might break anything for Cygwin, but have not >>received any reply from their developers. Maybe I should just check it >>in anyway, and see if they scream? I'd like to get the unnecessary >>cruft out of the CVS copies, before we publish, if we do decide to go >>for 3.10.1. > >The surest way to find that out is to commit the patch. You'll know in >a few hours if it breaks a Cygwin build. That strikes me as a pretty unfriendly way to approach this. You might notice that Corinna submitted her patch for consideration. I don't see any reason for anyone in the MinGW project to be any less courteous. cgf |
From: Keith M. <kei...@us...> - 2006-09-11 20:56:28
|
On Monday 11 September 2006 3:00 pm, Christopher Faylor wrote: > On Mon, Sep 11, 2006 at 08:02:18AM -0400, Earnie Boyd wrote: > >Quoting Keith Marshall <kei...@us...>: > >>BTW, I've proven that patch for MinGW only, and haven't yet committed > >>it. I asked if it might break anything for Cygwin, but have not > >>received any reply from their developers. Maybe I should just check > >> it in anyway, and see if they scream? I'd like to get the > >> unnecessary cruft out of the CVS copies, before we publish, if we do > >> decide to go for 3.10.1. > > > >The surest way to find that out is to commit the patch. You'll know > > in a few hours if it breaks a Cygwin build. > > That strikes me as a pretty unfriendly way to approach this. > > You might notice that Corinna submitted her patch for consideration. I > don't see any reason for anyone in the MinGW project to be any less > courteous. And I share that opinion, which is why I did submit my patch for comment, more that a week ago. The only comment I received was your own, which didn't really address the patch, but expressed your disagreement with my view on the use of aclocal to compile aclocal.m4. I don't wish to make a big deal of that disagreement, but I remain of my original opinion; we will just have to agree to disagree. However, I would just like to point out that the maintainer of aclocal himself says, in the latest automake texinfo documentation, that aclocal should never be invoked other than implicitly by autoreconf. To reinforce the point, I would refer you to the aclocal.m4 in the w32api module; this comprises 831 lines generated by aclocal, not one of which serves any useful purpose whatsoever, for nothing therein is ever referenced by configure.in -- you might just as well delete aclocal.m4 in its entirety, for it just isn't used. But to return to the patch; on the assumption that no contrary comment in over a week amounts to tacit approval, I committed it yesterday, and I haven't seen any cries of `foul'. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2006-09-11 23:30:48
|
Quoting Christopher Faylor <me...@cg...>: > On Mon, Sep 11, 2006 at 08:02:18AM -0400, Earnie Boyd wrote: >> Quoting Keith Marshall <kei...@us...>: >>> BTW, I've proven that patch for MinGW only, and haven't yet committed >>> it. I asked if it might break anything for Cygwin, but have not >>> received any reply from their developers. Maybe I should just check it >>> in anyway, and see if they scream? I'd like to get the unnecessary >>> cruft out of the CVS copies, before we publish, if we do decide to go >>> for 3.10.1. >> >> The surest way to find that out is to commit the patch. You'll know in >> a few hours if it breaks a Cygwin build. > > That strikes me as a pretty unfriendly way to approach this. > I should have smily faced it. Sorry. Earnie Boyd http://shop.siebunlimited.com |
From: Christopher F. <me...@cg...> - 2006-09-12 02:02:51
|
On Mon, Sep 11, 2006 at 07:30:45PM -0400, Earnie Boyd wrote: >Quoting Christopher Faylor <me...@cg...>: > >> On Mon, Sep 11, 2006 at 08:02:18AM -0400, Earnie Boyd wrote: >>> Quoting Keith Marshall <kei...@us...>: >>>> BTW, I've proven that patch for MinGW only, and haven't yet committed >>>> it. I asked if it might break anything for Cygwin, but have not >>>> received any reply from their developers. Maybe I should just check it >>>> in anyway, and see if they scream? I'd like to get the unnecessary >>>> cruft out of the CVS copies, before we publish, if we do decide to go >>>> for 3.10.1. >>> >>> The surest way to find that out is to commit the patch. You'll know in >>> a few hours if it breaks a Cygwin build. >> >> That strikes me as a pretty unfriendly way to approach this. > >I should have smily faced it. Sorry. Aha! Sorry for not getting it. cgf |
From: Chris S. <ir0...@gm...> - 2006-09-12 00:01:13
|
> But to return to the patch; on the assumption that no contrary comment in > over a week amounts to tacit approval, I committed it yesterday, and I > haven't seen any cries of `foul'. Just curious, where did you apply it? I haven't seen it in CVS. Are you referring to the runtime snapshot? Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org |
From: Keith M. <kei...@us...> - 2006-09-12 18:47:24
|
On Tuesday 12 September 2006 1:01 am, Chris Sutcliffe wrote: > > But to return to the patch; on the assumption that no contrary > > comment in over a week amounts to tacit approval, I committed it > > yesterday, and I haven't seen any cries of `foul'. > > Just curious, where did you apply it? I haven't seen it in CVS. Are > you referring to the runtime snapshot? Nope. It is in CVS: http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/ChangeLog?cvsroot=src http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/aclocal.m4?cvsroot=src http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/configure.in?cvsroot=src http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/configure?cvsroot=src Cheers, Keith. |