Re: make check failure (was: glib under mingw32 debian cross compiler, problem with windres : gmodule-win32res.lo: file not recognized: File format not recognized)

Hi,

my experiences are not related to the debian cross mingw but to a
native mingw build.  Anyway ...

The problem with .lo files which are generated by lt-compile-resource
is that the ltmain.sh script distributed with glib (at least in 2.0.4,
I didn't try 2.0.6 yet) is too old to support the format of .lo files
as generated by lt-compile-resource (older ltmain.sh produced and read
only binary .lo files which were essentially the same as or very
similar to normal .o files produced by the compiler; newer ones just
use simple shell scripts).  Therefore you will need a sufficiently
recent libtool version.  If the libtool 1.4.2 used in debian woody is
recent enough, you will have to try out; but I would guess it is.

The easiest thing you can do is replacing glib's ltmain.sh (just
overwriting it) with a more recent one.  The resulting libtool script
will be slightly broken because the configure process misses one or
two additional shell variables that are needed by recent ltmain.sh
files.  You can solve that by either running aclocal, autoconf,
automake and libtoolize (these steps result in a running libtool after
configure has been executed) or by adding the missing variables
manually (to the libtool script generated by configure; I just
remember the 'SED' variable which should evaluate to your sed
executable, but there may be one or two more, e.g. 'SED=sed', if it's
in your PATH).

To be honest that was the easier part of the autotools build with
mingw.  I've written a summary about what was needed for me to get
glib built.  Look at
http://mail.gnome.org/archives/gtk-list/2002-August/msg00198.html,
perhaps it can help you also with cross compiling.  I attach a newer
libtool patch.  Please note that this patch doesn't solve the
mentioned ltmain.sh problem.  Its purpose is mostly to replace the
command for building shared libs (i.e. dlls), i.e. the
'archive_expsym_cmds' in the libtool script, with mingw plus some
minor tweaks.  The generated build command didn't work for me and
seemed to be valid only for older binutils, i.e. ld.  The source for
the patch is mostly cygwin's libtool-dev package with minor changes,
for instance for the usage of .def files (which glib uses).  So
cygwin's Robert Collins (libtool maintainer) deserves the credits.

In the meantime I've also managed to build a stock libiconv-1.8 and
the mingw port of gettext-0.10.40 (I think I found it at
gnuwin32.sf.net) with Tor's patch for libintl and some minor tweaks
(mostly related to inclusion of param.h which isn't available in the
stock mingw distribution; the configure script checks for its
existance but some source incude it unconditionally; fortunately these
sources don't use any definitions from the header so you can just add
the usual preprocessor #ifdef HAVE_PARAM_H around the #include).  Both
of these packages just needed a very similar libtool patch as
attached.  If you try it yourself, you will also need to remember that
you have to 'chmod a+x' all generated dlls (at least on NTFS) because
they use the INSTALL_DATA macro for installation, which isn't a good
idea on windows.  The 'make check' failed miserably for both but this
was just because of the usual 'CRLF' hassle, AFAICS.  I found no easy
way to fix this problem and just left it alone.

The 'make check' of glib runs very smoothly.  It just reports one
failure in 29 testcases.  The failure is due to the strtod testcase.
It seems to me that a M$ runtime breakage is responsible for it.  I've
attached a very simple testcase so that you can reproduce the failure.
In it, the last test with the double value generated by 'pow'
ressembles closely the glib strtod testcase.  It seems that M$'s pow
implementation generates doubles which are smaller than DBL_MIN (in
float.h).  'sprintf' also happily deals with it, but only strtod does
the right thing and returns that it's 0.0.  This is just my
interpretation and I'm anything but a floating point expert.  In any
case the behaviour of the runtime functions is inconsistent.  The
programs output is exactly the same with mingw and VC6-SP5's cl.exe,
so it's clear that this is not a mingw issue.  BTW, cygwin's gcc does
the right thing.

I couldn't come up with an easy fix for glib (I'm not sure that one is
neede) but I thought you would be interested to know for some of you.
Perhaps glib's strtod testcase can be changed to circumvent this
problem.


cheers,

andreas