[prev in list] [next in list] [prev in thread] [next in thread]
List: cygwin
Subject: Re: trying to complibe glib 2.0.7
From: Charles Wilson <cwilson () ece ! gatech ! edu>
Date: 2002-12-30 20:08:14
[Download RAW message or body]
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
["glib-2.0.7.NOTES" (text/plain)]
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" (application/x-gzip)]
--
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/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic