I know very well the spirit of MinGW, it want to provide a native Win32
development evrionment.
The issue is : many of the host tools have not been ported or very hard to
be ported to pure MinGW/Win32 environment, for example, bash. This is why
Msys exist. Msys essensially a fork of Cygwin 1.3. In MinGW's download
page, there are two kinds of packages to download, MinGW pacakges and Msys
packages. The MinGW packages are packages ported to pure MinGW/Win32
environment, not linked to non standard DLLs, like, cygwin1.dll or
msys-1.0.dll. The Msys packages are packages developed in a outdated
developent toolchain(gcc-2.9), and linked to msys-1.0.dll. The Msys packages
are not native MinGW/Win32 packages, just like Cygwin packages.
The existence of Msys proves that : in MinGW, you must provide a
additional/optional newlib style library, the headers,libs, to make a bundle
of tools to be build easily : bash, make, coreutils, bzip2,diffutils, file,
findutils, gawk, grep, gzip, less, m4, patch, sed, tar, texinfo, perl, etc.
The testruns for 32-bit and 64-bit of mingw-w64 are done on a linux host by
cross-compilation and are executed on a remote Windows host, again confirm
this points : MinGW lack the the native ported MinGW/Win32 tools.
I know that a lot of basic tools like, make,dmake, perl, tck/tk have been
ported to pure MinGW/Win32 evnrironment. Autoconf, automake, libtool, depend
on perl, but I don't know whether not pure MinGW/Win32 perl works.
I also notice that there a GnuWin32 project, but no prove exists that we
can use that as gcc development environment.
It seems that all GNU development tools have been ported to Cygwin, with the
latest version. But in Msys, many tools are missing or outdated. In some
meaning , Cygwin seems more successful than MinGW+Msys.
It would be very nice when Cygwin can masquerade as MinGW. I have tried to
relpace the uname.exe in Cygwin's bin directory(c:/cygwin/bin), with the one
in MinGW is bin directory(c:/msys/1.0/bin). Then in Cygwin bash when run
"config.guess", it print "i686-pc-mingw32". For lack of time, I have not
done further test.
cheers.
Chiheng Xu
Wuhan,China
-邮件原件-
发件人: Kai Tietz [mailto:ktiet...@googlemail.com]
发送时间: 2009年11月9日 19:04
收件人: Kai Ruottu
抄送: 徐持恒; gcc@gcc.gnu.org
主题: Re: How to run gcc test suite in pure mingw32 environment?
2009/11/9 Kai Ruottu :
> 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.
The testruns we do for 32-bit and 64-bit of mingw-w64 are done on a
linux host by cross-compilation and are executed on a remote Windows
host. ssh and rexec can be used here. NightStrike can give here more
details.
> 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...
Indeed, to make a cross-compiler (especially on cygwin and linux)
makes absolutely sense. In fact it is at the moment (as the expect
tool isn't ported for native Windows hosts) the only way to do
regression tests.
>> Is't it necessary to port newlib to pure MinGW environment ?
This makes no sense. Possibly your initial idea here isn't
understandable, so could you give us more details about this?
Regards,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
