徐持恒 wrote: > These days, I’m trying to build gcc-4.4.2 + binutils-2.20 + gmp + mpfr in > Msys+MinGW and Cygwin environment. > > The builds on both environments are OK, but I cannot run "make check", or > "make check-gcc". > > Finally, I found, that, to run test, you must first install guile, autogen, > tck/tk, expect, dejagnu. >
This "self-hosted" idea is quite the same as trying to produce cars in garages or even on roads because they will be used there... I myself would be more interested to get these tests for MinGW-hosted tools to work on Linux because that is the "preferred build platform for MinGW-hosted tools" for me. Some years ago I produced more than 100 binutils+GCC+GDB/Insight toolchains for all kind of targets to be run on the MinGW runtime host. Just for a fun... The tests regarding to "does it work" happening on Windoze/MinGW via compiling apps there and then possibly running them on the built-in simulator in GDB or using the standalone "$target-run" simulator on the console. When all the $target systems for the MinGW-hosted binutils, GCCs and GDB/Insights are non-Windoze targets, the question is about how well these tools would work on Windoze and are the results from them identical with their equivalents on the primary Linux host. What maybe could be usable, would be some kind of "gdbserver" to run on Windoze and run the MinGW-hosted toolchain tests "natively" there. What has been the "problem" is that those very limited tests on the Windoze/MinGW host have this far showed the toolchains to work quite identically with their earlier equivalents on the Linux host, for instance a toolchain for "arm-elf" on MinGW-host working nicely on Windoze too. So really no need to wonder how to get "make check" to work with the Canadian-cross built toolchains... > Is't it necessary to port newlib to pure MinGW environment ? I tried to understand what this clause means but didn't "grok" it... Could you elaborate what the point is? "Pure MinGW" means "running apps using the native Windoze DLLs" meanwhile Cygwin (and MSYS?) try to provide a "Unix layer" for the apps like binutils, GCC and GDB. For instance the tcl/tk/itcl DLLs are for Win32 API in the MinGW-hosted Insights... > If we have test environment on Windows platform, we can greatly improve the > development process in this platform ,and ensure the quality of gcc and > companion tools on Windows. I noticed that there are also a MinGW-w64 > project, if we have that test environment, we can impove it, even accelerate > it. > When producing those 100+ toolchains for MinGW, my conclusion was : "In the same time when one developer builds 100 toolchains for MinGW host on a productive build platform, there must be 100 developers to get just one toolchain (for MinGW target) being built on the native Windoze build platform :( Just name your $target(s) and I will report how many minutes it takes to build gcc-4.4.2 + binutils-2.20 (and the gmp + mpfr for MinGW host) for it and for MinGW $host on Linux $build host.... Producing Insight 6.8 for MinGW host and for a couple of targets like 'mips-elf' seemed to work nicely on July 2009 but some targets might still be problems with the MinGW $host. For instance making a remote debugger for 'sparc-solaris2.11' or some embedded Linux target to run on MinGW host....
