glib-2.2.0 on cygwin

[Charles Wilson <cwilson at ece dot gatech dot edu>]

I finally got the 2.0.7 patches forward-ported to 2.2.0 -- they went 
thru quite a metamorphosis.  But, by applying the attached patch and 
following the instructions below, glib-2.2.0 will

1) build as shared libs
2) pass 27 of 29 tests  (yep, regressions...see NOTES below for analysis)

Please read the attached NOTES file thoroughly -- it is quite different 
from the one included with the glib-2.0.7 message.   It is especially 
useful if you're thinking about turning this simple patch into a 
full-blown set of cygwin packages -- or if you want to help fix the two 
test regressions.

[Note that the attached patch affects only the primary sources;  after 
running the bootstrap script the patch grows to almost 1.9MB]

--Chuck


build requirements:
==================================

pkgconfig      0.14.0 or newer
libtool
libtool-devel  20021227-1 or newer (*)
autoconf
autoconf-devel 2.57-1 or newer
automake
automake-devel 1.7.2-1 or newer
gcc            3.2-3 or newer
binutils       20021117-1 or newer
libiconv       1.8-2
libiconv2      1.8-2
libintl2       0.11.5-1
gettext        0.11.5-1            
gettext-devel	0.11.5-1            

(*) if using 20021227-1, you need to apply the following patch to
/usr/autotools/devel/share/aclocal/libtool.m4 BEFORE running bootstrap,
below.  I'll release a new libtool that includes this fix soon.

--- libtool.m4.orig   2002-12-30 00:16:43.000000000 -0500
+++ libtool.m4        2002-12-30 00:16:56.000000000 -0500
@@ -2342,7 +2342,7 @@
 # --------------
 # enable support for Windows resource files
 AC_DEFUN([AC_LIBTOOL_RC],
-[AC_REQUIRE([AC_PROG_RC])
+[AC_REQUIRE([LT_AC_PROG_RC])
 _LT_AC_SHELL_INIT([tagnames=`echo "$tagnames,RC" | sed 's/^,//'`])
 ])# AC_LIBTOOL_RC


build instructions:
==================================
This is what I did, but you might want different CFLAGS or configure options.

1) unpack glib-2.2.0.tar.bz2
2) cd glib-2.2.0
3) patch -p1 < <path to>/glib-2.2.0.patch
4) chmod +x ./bootstrap
5) ./bootstrap
6) mkdir .build && cd .build
7) CFLAGS='-g -O0' ../configure \
   --prefix=/usr/local --srcdir=<path to>/glib-2.2.0 --enable-maintainer-mode
8) make


test results:
==================================
failed 2 of 29 tests -- see below


packaging notes:
==================================
I don't intend to package glib for cygwin, or to support it.  I just 
viewed it as an interesting application/testcase for libtool.  If anyone 
wants to take these patches and use them to provide an official glib
package for cygwin, I wouldn't mind -- but be warned, the packaging will 
be tricky, since the import libs and headers are versioned, as well as 
the dll.  See Nicholas Wourm's packaging structure for
  db2
  libdb2
  libdb2-devel
  db3.1
  libdb3.1
  libdb3.1-devel

I'd suggest [NOTE: glib20 NOT glib22, libglib20_0 NOT libglib22_0. This is
because glib-2.2 is backward compatible with glib-2.0]

  glib20-devel-2.2.0-1
    (include files, import libs, locale files, static libs,
    pkg-config files (.pc), glib-2.0.m4, but not glib-gettext.m4)
	 
  libglib20_0-2.2.0-1
    (contains only the dlls) 

  glib-docs-2.2.0-1
    (html docs, but not the man pages)

  glib-2.2.0-1
    (everything else, incl. glib-gettext.m4, .exe's, man pages)

Oh -- and don't "ship" usr/lib/charset.alias.  That's part of the gettext 
package on cygwin.

submitting "upstream"
==================================
These patches are probably large enough that I'd need to fill out 
a copyright assignment for glib.  I wouldn't mind doing that, if someone
else wants to push them into glib-2.2.1.  (Also, Steven O'Brien would 
need to fill out a copyright assignment too).

But....

These patches depend on reautotoolizing the whole tree using CVS versions 
of libtool.  There might be resistance to that -- at least until libtool-1.5
is released officially.

porting notes:
==================================
My "solution" for the earlier string-test failures is cheezy.  The problem is
actually in newlib's routines that format floating point numbers; hopefully
they will be fixed soon.  However, I just reduced the %10000.10000f down to
the maximum that newlib can handle: %42.42f.

There are a number of places where I blithely replaced G_PLATFORM_WIN32 
with G_OS_WIN32 (thus skipping various win32-isms on cygwin, and using 
the unix-isms instead).  I tried to only do this where it made sense -- 
and I kept some win32-isms.  However, it is entirely possible that SOME 
of the win32-isms that I killed in the cygwin build are actually needed, 
especially as it relates to g_convert_filename functions dealing with 
internationalization. 

-----
module-test will fail unless you use a very very new ld.  There was
a patch posted recently to binutils mailing list that enables .exe's to
have exports, without going thru the gyrations that were necessary
previously.  It is likely that the patch will be accepted soon, and
that there will be included in an official cygwin binutils release 
somewhat later.

For an executable to dlsym() symbols from itself, the executable 
must have an exports table.  Older (and current) ld's do not 
create export tables, even if some objects used to build the 
exe have __declspec() decorated symbols.  Nor did --export-all-symbols
have any effect.

Instead, the old method (as used in glib-2.0.7, and by G_OS_WIN32 in
2.2.0) was the following:
  1) use dlltool to create an .exp file from the object files (which
     already contains "decorated" symbols).  An .exp file is a 
     binary block that is incorporated directly into the .exe itself.
       dlltool --output-exp my.exp one.o two.o three.o
  2) add the .exp file to the list of dependencies for the executable,
     so that it is incorporated into the binary.
       gcc -o foo.exe one.o two.o three.o my.exp

The new method, assuming you have a very very new ld, is just
  gcc -o foo.exe one.o two.o three.o
Since the desired symbols in one.o/two.o/three.o should already be 
decorated with __declspec(dllexport) or G_MODULE_EXPORT, the new 
ld will take care of building the export table behind the scenes.  
No need for dlltool.

This port is forward-looking.  Rather than keep the old, kludgy 
dlltool-based method, we assume that you have a newer ld (even 
if it isn't really available quite yet).  We use the new method
to build module-test.exe.
-----

Tip Of Hat: Many of these changes originated with Steven O'Brien
http://homepage.ntlworld.com/steven.obrien2/  Also, the basic port
to window-ish platforms is due to TONS of work by Tor Lilqvist and his
elves on the gimpwin-dev@yahoogroups.com list.

NOTES ON TEST RESULTS:  FAILED--
=================================================

strtod-test
type-test

The actual failures are the real problem.  But there's another problem:
WHEN a test fails, we get a kernel message "wait for sig_complete..."
Worse, the test will then spin at 100% CPU, making it very difficult 
to kill the executable.

IMO, the *first* thing to do is track down why the tests behave so
poorly on failure.  Is it something in glib's atexit handler?  Is 
there (another) bug in cygwin?

answer (maybe):
---------------
I had the following in my CYGWIN variable:
  error_start:d:/cygwin/bin/dumper.exe
Once I removed it, the tests still failed, but at least I didn't
get the 100% CPU and 'wait for sig-complete event failed' thing,
I got a simple (old-style) .stackdump file and returned to
the command prompt.  So is this a dumper bug?  Or maybe yesterday's
cygwin snapshot fixes it?
---------------

Once that's been tracked down and fixed, then worry about what 
causes the specific failures in these three tests.

************** OLD, WITH DUMPER OUTPUT **********************

** ERROR **: file /usr/local/src/glib/glib-2.2.0/glib-2.2.0/tests/strtod-test.c: line 46 (main): assertion failed: (d == g_ascii_strtod (g_ascii_dtostr (buffer, sizeof (buffer), d), NULL))
aborting...
4005742 [main] lt-strtod-test 712 sig_send: wait for sig_complete event failed, signal 6, rc 258, Win32 error 0
64051451 [main] lt-strtod-test 712 sig_send: wait for sig_complete event failed, signal -2, rc 258, Win32 error 0
128043819 [main] lt-strtod-test 712 sig_send: wait for sig_complete event failed, signal -2, rc 258, Win32 error 0
192055605 [main] lt-strtod-test 712 sig_send: wait for sig_complete event failed, signal -2, rc 258, Win32 error 0
252112186 [main] lt-strtod-test 712 sig_send: wait for sig_complete event failed, signal -2, rc 258, Win32 error 0
FAIL: strtod-test


** ERROR **: file /usr/local/src/glib/glib-2.2.0/glib-2.2.0/tests/type-test.c: line 118 (main): assertion failed: (gi64t1 == gi64t2)
aborting...
4007311 [main] lt-type-test 448 sig_send: wait for sig_complete event failed, signal 6, rc 258, Win32 error 0
67056172 [main] lt-type-test 448 sig_send: wait for sig_complete event failed, signal -2, rc 258, Win32 error 0
FAIL: type-test


************** NEW, NO DUMPER OUTPUT **********************

strtod-test:

** ERROR **: file /usr/local/src/glib/glib-2.2.0/glib-2.2.0/tests/strtod-test.c: line 46 (main): assertion failed: (d == g_ascii_strtod (g_ascii_dtostr (buffer, sizeof (buffer), d), NULL))
aborting...
Aborted (core dumped)

type-test:

** ERROR **: file /usr/local/src/glib/glib-2.2.0/glib-2.2.0/tests/type-test.c: line 118 (main): assertion failed: (gi64t1 == gi64t2)
aborting...
Aborted (core dumped)

************** ANALYSIS **********************

strtod-test

The glib folks wanted to guarantee that "positional
parameters" in printf format strings would be supported.  

Of course, newlib as provided by cygwin does not -- you must
compile newlib with WANT_IO_POS_ARGS for that.  By default, 
the following special defines are used when cygwin is built:
  -DMB_CAPABLE -DHAVE_OPENDIR -DHAVE_RENAME -DSIGNAL_PROVIDED 
  -DWANT_IO_LONG_DBL -DWANT_PRINTF_LONG_LONG -D_COMPILING_NEWLIB 
  -DHAVE_FCNTL -DMALLOC_PROVIDED
So, our newlib supports printing long longs (64 bits).
But, it doesn't do sscanf for 64bit entries, and it doesn't
do positional parameters.

On systems that do not provide positional parameter support,
glib will use the included trio library to replace printf
functions.

So here's the problem: 
  g_ascii_dtostr (buffer, sizeof (buffer), d)
dies in three of the four tests: 
  d = a really really big negative floating point constant
  d = pow (2.0, -1024.1)
  d = -pow (2.0, -1024.1)
  <passed>:
  d = a really really big positive floating point constant
but all 4 tests passed in 2.0.7!

Well, in 2.0.7, g_ascii_dtostr() eventually calls the system
printf (newlib).  However, in 2.2.0, it calls the trio printf.
Which seems to be broken on cygwin.  So that's where I'd look 
when tracking down this problem.



type-test:

It fails the following test:
  string = g_strdup_printf (FORMAT64, gi64t1, gu64t1);
  sscanf (string, FORMAT64, &gi64t2, &gu64t2);
  g_free (string);
  g_assert (gi64t1 == gi64t2);
  g_assert (gu64t1 == gu64t2);a
That is, it writes out 64 bit ints, but doesn't accurately
read them in.  That's because newlib's sscanf will happily 
accept a "%llu" type specifier -- but gets it hopeless wrong
reading in the data.

Two solutions:
  (Assuming the above problem with trio printf is fixed), follow
  the same pattern and use trio's sscanf functions to replace
  the system ones.  The code is in the glib/trio directory, but
  for some reason is unused.

  or

  Fix newlib to accurately sscanf 64 bit values.

Attachment: glib-2.2.0-cygwin.patch.gz
Description: GNU Zip compressed data

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/