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]

Re: trying to complibe glib 2.0.7

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

build requirements:

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:

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 ",
          " wuss.  everyone agrees.\n",
          10, 666, 15, 15, 666.666666666, 666.666666666);

death occurs in 
  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:
Bug reporting:

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