On Wed, 2004-04-21 at 09:18, Daniel Eischen wrote: > 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.
I had another thought based on your comments. Since -pthread does the right thing in -CURRENT, why don't we make that the default PTHREAD_LIBS? Why do we explicitly link to -lpthread when that causes shared libs to be linked to threading libraries? If we did -pthread universally, this problem would go away because ORBit would do the right thing in the non-threaded case. Joe -- Joe Marcus Clarke FreeBSD GNOME Team :: [EMAIL PROTECTED] [EMAIL PROTECTED] FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome
signature.asc
Description: This is a digitally signed message part
