Subject: Re: galeon vs. -current
To: None <>
From: Shin'ichiro TAYA <>
List: tech-pkg
Date: 02/26/2003 22:05:59
From: Hubert Feyrer <>
Subject: galeon vs. -current
Date: Wed, 26 Feb 2003 13:53:21 +0100 (MET)

> noon% galeon
> /usr/X11R6/lib/vfs/modules/ Undefined PLT symbol
> "gnome_vfs_pthread_recursive_mutex_init" (symnum = 52)
> Has anyone seen this? Any suggested fixes?
> This is latest galeon on -current/i386.

See the discussion today.

From: "Nathan J. Williams" <>
Subject: devel/glib workaround
Date: 25 Feb 2003 13:14:19 -0500

> I've found that the glib package has broken gmodule support in
> -current do to an interaction between one of its configure tests and
> libpthread. The problem manifests as an inability to find symbols in
> gmodule-opened shared objects, such as the error reported in PR 20050:
> $ galeon
> /usr/X11R6/lib/vfs/modules/ Undefined PLT symbol
> "gnome_vfs_pthread_recursive_mutex_init" 
> The problem is that glib has a configure test for some broken
> RTLD_GLOBAL behavior on OSF/1, and the test calls
> dlopen(""). The test succeds in finding that NetBSD's
> dlopen isn't broken in the way that OSF/1 is or was, but then it
> triggers an assertion on exit (inside the mutex locking in atexit(),
> where one of the libc pthread stubs correctly detects that libpthread
> has been loaded and it shouldn't be running), and the abort/core dump
> is read by configure as the test reporting "broken, OSF/1 style".
> Making it safe to dynamically load and use is pretty
> unlikely (as best I can tell, only AIX currently supports that, and
> most of the industry thinks "ow, what a bad idea"), and so I'd prefer
> to keep the behavior that the libc routines detect this and fail
> noisily rather than silently. So I'd like to patch glib in pkgsrc to
> avoid this problem, by removing the relevant configure test.
> The patches are attached; comments requested.
>         - Nathan