Date: Tue, 20 Apr 2004 17:08:38 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Joe Marcus Clarke <marcus@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Help: threading problem in non-threaded applications Message-ID: <Pine.GSO.4.10.10404201652240.14017-100000@pcnet5.pcnet.com> In-Reply-To: <1082493900.837.79.camel@gyros>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 20 Apr 2004, Joe Marcus Clarke wrote: > I have a problem I'm hoping someone can help me with. GTK+ 2.4 > introduced a new file selection GUI which works just fine in threaded > and non-threaded applications. However, GNOME 2.6 augmented this dialog > with a dynamically loadable threaded shared object. The GNOME version > is automatically used by all GTK+ apps when run under a GNOME desktop if > libgnomeui is installed. Shared libraries shouldn't link with threading libraries unless they actually create threads behind the scenes. Actually, even so, they could force the (unthreaded) applications that link with them to explicitly supply the thread library in the link option. > When this object is dynamically loaded into GNOME applications, they work > just fine as they are linked to a thread library. However, when a GTK+ > non-threaded app tries to load this object, I get a segmentation fault > because the pthread_cond_wait() symbol gets found in libc before the thread > library, and threaded locking isn't setup. I've tried a lot of things to > try and fix this. I tried using dlopen/dlsym to resolve pthread_cond_wait > from the thread library, but this doesn't work. I tried setting > __isthreaded to 1, but that didn't work (it gets overridden). The only > thing that works is to set LD_PRELOAD to the thread library before running > the non-threaded app (or fixing the app to link against PTHREAD_LIBS). > > Is there a better solution to this? This problem only seems to affect > 5.X. I'm hoping not to have to link every GTK+ app that might use the > new file selector to PTHREAD_LIBS. Any advice would be greatly > appreciated. Thanks. Try using -pthread to build the shared library instead of -lpthread. That will avoid the link to libpthread. If it's only locking that the library needs, libc should have all the necessary stubs. An alternative is to get GNOME maintainers to use a thread stub library and have their shared libraries link to that. The stub library would provide weak locking symbols and be overridden by applications bringing in real thread libraries. Perhaps something like that could work. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10404201652240.14017-100000>