From: Chris S. <ir0...@gm...> - 2007-03-06 16:56:30
|
Hey All, Danny, do the recent changes you made to runtime to address Vista issues warrant a new runtime being released? Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org |
From: Brandon S. <br...@oq...> - 2007-03-06 18:39:43
|
can i sneak in some last minute stuff? B On Mar 6, 2007, at 8:56 AM, Chris Sutcliffe wrote: > Hey All, > > Danny, do the recent changes you made to runtime to address Vista > issues warrant a new runtime being released? > > Chris > > -- > Chris Sutcliffe > http://ir0nh34d.googlepages.com > http://ir0nh34d.blogspot.com > http://emergedesktop.org > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Chris S. <ir0...@gm...> - 2007-03-06 22:24:42
|
> can i sneak in some last minute stuff? By all means, just send a patch. Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org |
From: Keith M. <kei...@us...> - 2007-03-07 23:10:06
|
On Tuesday 06 March 2007 16:56, Chris Sutcliffe wrote: > Danny, do the recent changes you made to runtime to address Vista > issues warrant a new runtime being released? Please hold off till next week, Chris. I've still got a manpage, and some i18n patches, to add for `basename' and `dirname' functions; I hope to push these through this weekend. Cheers, Keith. |
From: Chris S. <ir0...@gm...> - 2007-03-07 23:39:04
|
> Please hold off till next week, Chris. I've still got a manpage, and > some i18n patches, to add for `basename' and `dirname' functions; I > hope to push these through this weekend. No worries, I'll wait for you to let me know when you're done. Cheers! Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org |
From: Keith M. <kei...@us...> - 2007-03-08 23:08:35
|
On Wednesday 07 March 2007 23:39, Chris Sutcliffe wrote: > > Please hold off till next week, Chris. =A0I've still got a manpage, > > and some i18n patches, to add for `basename' and `dirname' > > functions; I hope to push these through this weekend. > > No worries, I'll wait for you to let me know when you're done. Chris, I just tried patching my manpage into my local copy of mingw-runtime,=20 then tried to make a bindist. Ran into a couple of snags: 1) Not sure how I should configure, but I had to override `conf_prefix',=20 with `make bindist conf_prefix=3D', to work around what looks to me like=20 a Makefile bug. This voodoo to co-exist with Cygwin is a real PITA; I=20 really must find time to clean it up. 2) I have one manpage source, which serves for two man pages. On *nix I=20 would just install the first, then make either a hard or a symbolic=20 link to map the second; for MinGW we can't use the symlink, but a hard=20 link would be ok on NTFS, but a copy would be needed for FAT32. I'm=20 thinking it's probably best to just code a copy, and have done with it,=20 rather than trying to do anything clever. Any thoughts? Cheers, Keith. |
From: Chris S. <ir0...@gm...> - 2007-03-09 12:03:56
|
Hey Keith, > 1) Not sure how I should configure, but I had to override `conf_prefix', > with `make bindist conf_prefix=', to work around what looks to me like > a Makefile bug. This voodoo to co-exist with Cygwin is a real PITA; I > really must find time to clean it up. I use this script I came up with: #!/bin/sh if [ "$1" != "install" ] && [ "$1" != "dist" ] then echo "usage: $0 [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 MNO_CYGWIN="-mno-cygwin" CFLAGS="-s -O3 -mtune=i686" $1 It strips the prefix so you just end up with /bin, /lib, etc. in the package (via the makefile of course). I've made the shell script such that it works both under MSYS and Cygwin (hence the no '-mno-cygwin' flag). If memory serves you compile from under Linux? That being the case, I imagine the cross-compile voodoo in the Makefile may not work for you, since the build, host and target will not all be the same. > 2) I have one manpage source, which serves for two man pages. On *nix I > would just install the first, then make either a hard or a symbolic > link to map the second; for MinGW we can't use the symlink, but a hard > link would be ok on NTFS, but a copy would be needed for FAT32. I'm > thinking it's probably best to just code a copy, and have done with it, > rather than trying to do anything clever. Any thoughts? I agree with just doing a copy, given that MSYS doesn't support links and hard links would introduce a dependency on the type of file system. Cheers! Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org |
From: Keith M. <kei...@us...> - 2007-03-11 00:22:52
|
Hi Chris, On Friday 09 March 2007 12:03, Chris Sutcliffe wrote: > Hey Keith, > > > 1) Not sure how I should configure, but I had to override > > `conf_prefix', with `make bindist conf_prefix=', to work around > > what looks to me like a Makefile bug. This voodoo to co-exist with > > Cygwin is a real PITA; I really must find time to clean it up. > > I use this script I came up with: > [...snip...] > HOST_TYPE=i386-pc-mingw32 > PACKAGE=runtime > PREFIX=/mingw > [...snip...] > ../../$PACKAGE/configure --build=$HOST_TYPE --host=$HOST_TYPE \ > --target=$HOST_TYPE --prefix=$PREFIX > make MNO_CYGWIN="-mno-cygwin" CFLAGS="-s -O3 -mtune=i686" $1 > > It strips the prefix so you just end up with /bin, /lib, etc. in the > package (via the makefile of course). That's what I was expecting, but it sure isn't what I'm getting. > I've made the shell script > such that it works both under MSYS and Cygwin (hence the no > '-mno-cygwin' flag). I'm not using Cygwin, so I don't expect the -mno-cygwin flag to be relevant to my case. > If memory serves you compile from under Linux? Yes, I do, using a cross-hosted compiler targetting `i586-mingw32', so I set `--prefix=/mingw --build=i686-pc-linux --host=i586-mingw32'. > That being the case, > I imagine the cross-compile voodoo in the Makefile may not work for > you, since the build, host and target will not all be the same. Exactly! However, given that I've specified the `i586-mingw32' host, I expect distribution packages to be built as if for a native build, *not* as they should be for a Cygwin sub-system, but I'm actually seeing this latter behaviour. Curiously, if I add `--target=i586-mingw32' to my configure options, I do then get the correct behaviour. The clue comes from the earlier discussion we had about building cross compilers; the logic in the Makefile is based on `target_os'. I said it then, and I'm even more convinced now; this is just plain *wrong*! I'm *not* building a cross compiler here; I'm simply *using* an existing cross-compiler to build a runtime library suite, for the host which that cross-compiler targets. I should *not* need to specify a `--target' here, and if I do, it should be ignored, as completely irrelevant, but it clearly isn't! > > 2) I have one manpage source, which serves for two man pages. On > > *nix I would just install the first, then make either a hard or a > > symbolic link to map the second; for MinGW we can't use the > > symlink, but a hard link would be ok on NTFS, but a copy would be > > needed for FAT32. I'm thinking it's probably best to just code a > > copy, and have done with it, rather than trying to do anything > > clever. Any thoughts? > > I agree with just doing a copy, given that MSYS doesn't support links > and hard links would introduce a dependency on the type of file > system. I've committed the single manpage source, `man/dirname.man', which should be included in the source tarball `as is'; it serves as a common source for two manpages, which should appear in the binary distribution as `man/man3/basename.3' and `man/man3/dirname.3'; please double check that these are added, with the correct relative path names, when you create the distribution tarballs. Cheers, Keith. |
From: Earnie B. <ea...@us...> - 2007-03-11 11:36:45
|
Quoting Keith Marshall <kei...@us...>: > > Curiously, if I add `--target=i586-mingw32' to my configure options, I > do then get the correct behaviour. The clue comes from the earlier > discussion we had about building cross compilers; the logic in the > Makefile is based on `target_os'. I said it then, and I'm even more > convinced now; this is just plain *wrong*! I'm *not* building a cross > compiler here; I'm simply *using* an existing cross-compiler to build a > runtime library suite, for the host which that cross-compiler targets. > I should *not* need to specify a `--target' here, and if I do, it > should be ignored, as completely irrelevant, but it clearly isn't! > I thought that if --target wasn't specified it was supposed to default to --host by way of autoconf magic. Perhaps there is a break down in how the value for target is getting set. Perhaps target_os is an old Cygnus thingy that isn't properly set unless you're building from a Cygnus style top level configure script. Cygnus top level configure scripts were not autoconf generated but were used to drive configure scripts in sub directories of the top level. Earnie |
From: Keith M. <kei...@us...> - 2007-03-11 14:46:39
|
On Sunday 11 March 2007 11:36, Earnie Boyd wrote: > I thought that if --target wasn't specified it was supposed to > default to --host by way of autoconf magic. Nope. AFAIK, that has never been the case, at least in autoconf generated configure scripts. > Perhaps there is a break > down in how the value for target is getting set. It should not be set at all, unless the user specifies `--target=foo', as an option to configure. It shouldn't need to be set, unless what you are building is a code generator, (compiler). The build/host/target relationship seems to be often misunderstood, even by well clued-up developers. Here's how it's intended to work: `build' is unequivocally the platform on which you are building your code; there seems to be little scope for misunderstanding here, and I think this is well enough understood. `host' is where whatever you are building is to be deployed; in the case of building an executable application, it's where that application may be invoked natively; in the case of building a runtime library, it is where applications linked against that library may be invoked natively. Thus, it is a specification of `--host=i686-mingw32', or similar, that is appropriate for building mingw-runtime. `target' is where code subsequently *generated* by whatever you are building will be deployed; it has absolutely no meaning when you are building anything other than a code generator, (compiler). Since mingw-runtime is *not* a compiler, (it is a simple runtime library), to require me to specify `target' when building it contravenes standard usage, and must be wrong. > Perhaps target_os > is an old Cygnus thingy that isn't properly set unless you're > building from a Cygnus style top level configure script. Nope. It is an autoconf feature; set when AC_CANONICAL_TARGET is used, either explicitly, or implicitly by AC_CANONICAL_SYSTEM, (which is used by our configure script). It will be defined as the OS specific component of the target triplet, *if* the user specifies `--target=...', or to nothing, (i.e. a zero length string), otherwise. > Cygnus top > level configure scripts were not autoconf generated but were used to > drive configure scripts in sub directories of the top level. Whether, or not, we once had to accommodate Cygnus conventions, today we use autoconf. IMO, we should adopt conventions which are consistent with autoconf standards; our mingw-runtime configury fails, in this respect, so I consider it to be broken. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2007-03-11 22:22:27
|
Quoting Keith Marshall <kei...@us...>: > >> Cygnus top >> level configure scripts were not autoconf generated but were used to >> drive configure scripts in sub directories of the top level. > > Whether, or not, we once had to accommodate Cygnus conventions, today we > use autoconf. IMO, we should adopt conventions which are consistent > with autoconf standards; our mingw-runtime configury fails, in this > respect, so I consider it to be broken. > I'm not saying it isn't broken. I was trying to remember why it was set to begin with. Perhaps it was my own confusion. Perhaps it has been too long to remember. Maybe C.F. was the creator of the Makefile code and all I did was tweak it here and there to make it work for my benefit without breaking the Cygwin build. Earnie |
From: Chris S. <ir0...@gm...> - 2007-03-17 13:09:23
|
Are we good for a new runtime build then? Should I change to using '-O2' as opposed to the '-O3' that I have been using given the discussion we've had regarding mingw32-make? Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org |
From: Keith M. <kei...@us...> - 2007-03-17 23:16:29
|
On Saturday 17 March 2007 13:09, Chris Sutcliffe wrote: > Are we good for a new runtime build then? Ok by me. > Should I change to using > '-O2' as opposed to the '-O3' that I have been using given the > discussion we've had regarding mingw32-make? Does anyone know how much of a performance gain we achieve with -O3, over -O2? I don't have any particularly strong preference either way, but GNU Coding Standards recommend -O2 for their projects, so I'm quite comfortable with using it for our own. OTOH, unless anyone can point to any bugs which disappear, as a result of switching to -O2, I'm equally comfortable with sticking with -O3. Regards, Keith. |
From: Gianluca S. <gi...@gm...> - 2007-03-17 23:31:16
|
On 3/18/07, Keith Marshall <kei...@us...> wrote: > Does anyone know how much of a performance gain we achieve with -O3, > over -O2? I don't have any particularly strong preference either way, > but GNU Coding Standards recommend -O2 for their projects, so I'm quite > comfortable with using it for our own. OTOH, unless anyone can point > to any bugs which disappear, as a result of switching to -O2, I'm > equally comfortable with sticking with -O3. I don't know the complete reasoning, nor to what extent is applicable to executables intended to run on Windows, but -O2 is the default optimization level on Red Hat based distros from a long time; from what I read in their ML -O3 gains are marginal on the performance side, while there are significant drawbacks while debugging applications. |
From: Earnie B. <ea...@us...> - 2007-03-18 04:42:56
|
Quoting Gianluca Sforna <gi...@gm...>: > On 3/18/07, Keith Marshall <kei...@us...> wrote: >> Does anyone know how much of a performance gain we achieve with -O3, >> over -O2? I don't have any particularly strong preference either way, >> but GNU Coding Standards recommend -O2 for their projects, so I'm quite >> comfortable with using it for our own. OTOH, unless anyone can point >> to any bugs which disappear, as a result of switching to -O2, I'm >> equally comfortable with sticking with -O3. > > I don't know the complete reasoning, nor to what extent is applicable > to executables intended to run on Windows, but -O2 is the default > optimization level on Red Hat based distros from a long time; from > what I read in their ML -O3 gains are marginal on the performance > side, while there are significant drawbacks while debugging > applications. > I don't know the gains either, my guess is none for mingw and w32api. The -O3 adds inline optimazations additionally over -O2. For debugging -O0 is what I use and recommend because any optimization may confuse where to look in the code including confusing the debugger but we are not talking about a debugging release. Earnie |
From: techtonik <tec...@us...> - 2007-03-18 08:38:08
|
On 3/18/07, Earnie Boyd <ea...@us...> wrote: > Quoting Gianluca Sforna <gi...@gm...>: > > > On 3/18/07, Keith Marshall <kei...@us...> wrote: > >> Does anyone know how much of a performance gain we achieve with -O3, > >> over -O2? I don't have any particularly strong preference either way, > >> but GNU Coding Standards recommend -O2 for their projects, so I'm quite > >> comfortable with using it for our own. OTOH, unless anyone can point > >> to any bugs which disappear, as a result of switching to -O2, I'm > >> equally comfortable with sticking with -O3. > > > > I don't know the complete reasoning, nor to what extent is applicable > > to executables intended to run on Windows, but -O2 is the default > > optimization level on Red Hat based distros from a long time; from > > what I read in their ML -O3 gains are marginal on the performance > > side, while there are significant drawbacks while debugging > > applications. > > > > I don't know the gains either, my guess is none for mingw and w32api. > The -O3 adds inline optimazations additionally over -O2. For debugging > -O0 is what I use and recommend because any optimization may confuse > where to look in the code including confusing the debugger but we are > not talking about a debugging release. It is possible to extract debugging information and build stacktraces with symbolic information from release binaries. It is the aim of breakpad project I''ve mentioned here some time ago. I am not an expert to say if -O3 switch will influence the process, but to me it seems that it is very likely to happen. -- --anatoly t. |
From: Gianluca S. <gi...@gm...> - 2007-03-18 08:57:23
|
On 3/18/07, techtonik <tec...@us...> wrote: > > I don't know the gains either, my guess is none for mingw and w32api. > > The -O3 adds inline optimazations additionally over -O2. For debugging > > -O0 is what I use and recommend because any optimization may confuse > > where to look in the code including confusing the debugger but we are > > not talking about a debugging release. > > It is possible to extract debugging information and build stacktraces > with symbolic information from release binaries. It is the aim of > breakpad project I''ve mentioned here some time ago. I am not an > expert to say if -O3 switch will influence the process, but to me it > seems that it is very likely to happen. Yes. RPMs are built using both -O2 and -g, then the debug info are stripped and put into a separate -debuginfo package: when one need to debug a binary, installing the -debuginfo bits is all that is needed (i.e. no recompilation with -g) to get started Again, I am not sure if this is applicable to Windows executables, nor if there is any interstest in such a feature for MinGW binaries. |