From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 21 06:18:41 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 4816A16A4CE; Wed, 21 Apr 2004 06:18:41 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEA6143D31; Wed, 21 Apr 2004 06:18:40 -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 i3LDIdtf002544; Wed, 21 Apr 2004 09:18:40 -0400 (EDT) Date: Wed, 21 Apr 2004 09:18:39 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Joe Marcus Clarke In-Reply-To: <1082524938.41182.26.camel@shumai.marcuscom.com> 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: Wed, 21 Apr 2004 13:18:41 -0000 On Wed, 21 Apr 2004, Joe Marcus Clarke wrote: > On Tue, 2004-04-20 at 17:08, Daniel Eischen wrote: > > 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. > > And that's the case here. The underlying libraries are creating and > using threads. But what happens when a non-threaded application loads a > thread library via dlopen() (which is the case here)? Here's the stack > trace I see: In that case you're going to have to link the application to a threads library. -- Dan Eischen