From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 20 14:08:39 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E822F16A4CE; Tue, 20 Apr 2004 14:08:39 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 438FB43D39; Tue, 20 Apr 2004 14:08:39 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i3KL8ctf019130; Tue, 20 Apr 2004 17:08:38 -0400 (EDT) Date: Tue, 20 Apr 2004 17:08:38 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Joe Marcus Clarke In-Reply-To: <1082493900.837.79.camel@gyros> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: Help: threading problem in non-threaded applications X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 21:08:40 -0000 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