Anyway, here's the scoop for glib-2.0.7. First, you need libtool-devel-20021227-1. (Then you have to hack it, because there is one tiny pre-existing bug that I didn't fix; I'll release a new version of libtool-devel that includes the fix later.)
Then, you need to patch glib-2.0.7, and reautotoolize the whole thing, using the handy bootstrap script included in the patch.
Then, configure, make. It passes all tests but one, and I *think* that one is actually a bug in cygwin's malloc routine. But I am NOT sure about that.
Anyway, this email has two attachments:
glib-2.0.7.NOTES === build instructions and requirements, including
what you need to do to your installed libtool. Also, a short semi-
analysis of the string-test.exe failure.
glib-2.0.7.patch.gz == the patch, gzip'ed for size. (does NOT include
the changes that reautotoolizing will introduce; THAT would be
1.8MB uncompressed)
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.
In general, the patches are based on Steven O'Brien's changes for glib-1.2.10, as well as some earlier work I had done. And the port owes a lot to Tor Lilqvist's work with glib+mingw/MSVC.
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 cygwin-glib package(s), 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
You'd probably want to do something like
glib20 (everything else)
glib20-devel (includes, import libs)
glib20-docs (html docs)
libglib20_0 (contains the dll)
I *may* update these patches to apply to glib-2.2.0, but no promises. I've been informed, however, that glib-2.2.0 requires pkgconfig-0.14. cygwin ships 0.12. Gee, I hope the maintainer releases an updated version of pkgconfig for cygwin...oh yeah, that's me. Sigh.
--Chuck
build requirements: ================================== 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:
==================================
1) unpack glib-2.0.7.tar.bz2
2) cd glib-2.0.7
3) patch -p1 < <path to>/glib-2.0.7.patch
4) chmod +x ./bootstrap
5) ./bootstrap
6) mkdir .build && cd .build
7) CFLAGS=-g ../configure --prefix=/usr/local --srcdir=<path to>/glib-2.0.7
--enable-maintainer-mode
8) make
test results:
==================================
string-test: FAIL
dies in this test:
g_string_sprintf (string2, "%s|%0100d|%s|%s|%0*d|%*.*f|%100.100f",
"this pete guy sure is a wuss, like he's the number ",
1,
" wuss. everyone agrees.\n",
string1->str,
10, 666, 15, 15, 666.666666666, 666.666666666);
death occurs in
g_string_printf
g_string_append_printf_internal
g_strdup_vprintf
g_new (gchar, g_printf_string_upper_bound(format,args1))
where second arg evaulates to 10324
g_new is #defined as
#define g_new(struct_type, n_structs) \
((struct_type *) g_malloc (((gsize) sizeof (struct_type)) * ((gsize)
(n_structs))))
so this call is ACTUALLY
(char *) g_malloc ( (sizeof (char)) * 10324 )
in g_malloc, we die at this line:
mem = glib_mem_vtable.malloc ( nbytes )
where nbytes is 10324
glib_mem_vtable.malloc = 0x10063b20 <malloc>
death is a SIGSEGV, and it must occur in malloc, and it corrupts the stack.
Haven't investigated this further, because you need a debuggable kernel and I
don't have time to build one right now.
glib-2.0.7.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/
