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 [EMAIL PROTECTED] 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.
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/