Odd behaviour when building on Win32 using MinGW

[Tor Lillqvist <tml iki fi>]

Espen Harlinn writes:
 > How I Invoke configure:
 > CC='gcc -O3 -mcpu=pentium4 -march=pentium4 -mmmx -msse -msse2
 > -mfpmath=sse -mthreads -mno-cygwin -mms-bitfields' CXX='g++
 > -mcpu=pentium4 -march=pentium4 -mmmx -msse -msse2 -mfpmath=sse -mthreads
 > -mno-cygwin -mms-bitfields' CPPFLAGS='-I/f/MinGW/include'
 > LDFLAGS='-L/f/MinGW/lib' configure --disable-static --prefix=/f/MinGW
 > --with-threads=win32 --build=i686-pc-mingw32

Hmm, if you can use paths like /f/MinGW then you are using the Cygwin
gcc (and linker). I am not saying that it doesn't work as well as the
mingw one (it's supposed to, as you use -mno-cygwin), it's just that I
haven't tried...

Good that you use --disable-static. Some magic probably should be
added to configure.in to forcibly do it on Win32.

Below I compare to the results I get with a glib-2-2 CVS from Monday
(should be practically identical to GLib 2.2.3).

 > FAIL: module-test

Hmm, that works for me. Hard to say what you problem is. Did libtool
put the libmoduletestplugin_a. and _b .dll files in .libs? Does your
libmod*.la files look OK? What happens if you move the .dll files to
the tests directory and run module-test, so that the program finds
them directly without the .la files?

 > FAIL: shell-test

Works here... No idea why it fails for you.

 > FAIL: spawn-test

Ditto...

 > Assertion failed: VALID(buffer), file trio.c, line 3941
 > abnormal program termination
 > FAIL: strfunc-test

Works here. I'm pretty certain this has been fixed in GLib 2.2.3.

 > FAIL: strtod-test

Fails here, too. Strtod-test expects too much of the system printf
and/or scanf.

 > FAIL: type-test

Hmm, fails here, too. Can't remember right now whether I have looked
more closely into this or not. In a hurry now, have to run...

--tml