From: Hubert Feyrer <hubert.feyrer@informatik.fh-regensburg.de>
Subject: galeon vs. -current
Date: Wed, 26 Feb 2003 13:53:21 +0100 (MET)

> 
> noon% galeon
> /usr/X11R6/lib/vfs/modules/libhttp.so: 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" <nathanw@wasabisystems.com>
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/libhttp.so: 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("libpthread.so"). 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 libpthread.so 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
>