Re: trying to complibe glib 2.0.7

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

Success with glib-2.0.7.  Just 8 days after the glib folks released the 
new stable version, glib-2.2.0.  Sigh.

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.

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