This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

glib-2.2.0 on cygwin

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]


build requirements:

pkgconfig      0.14.0 or newer
libtool-devel  20021227-1 or newer (*)
autoconf-devel 2.57-1 or newer
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
 _LT_AC_SHELL_INIT([tagnames=`echo "$tagnames,RC" | sed 's/^,//'`])

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

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]

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

    (html docs, but not the man pages)

    (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).


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 

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  Also, the basic port
to window-ish platforms is due to TONS of work by Tor Lilqvist and his
elves on the list.



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:
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))
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)
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 **********************


** 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))
Aborted (core dumped)


** 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)
Aborted (core dumped)

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


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:
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

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)
  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.


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.


  Fix newlib to accurately sscanf 64 bit values.

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

Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]