GNOME Bugzilla – Bug 600141
Add -pthread to gmodule pkg-config
Last modified: 2011-02-18 15:59:31 UTC
GIO uses threading in a bunch of places. Faking async jobs, GResolver and GThreadedSocketService come to mind. Running an app linked against GIO with gdb fails on my system with a message about threads: Cannot find new threads: generic error Adding -pthread to the compile/link commandline fixes this. I think we should have those in gio-2.0.pc, but I'm not sure.
I think just adding gthread-2.0 to the Requires line doesn't hurt, or will this cause lots of embedded people to haunt us?
all of those only use threads if someone else has called g_thread_init though, and that person would have to have linked with gthread-2.0 and hence libpthread. It seems like you just have a buggy version of gdb.
One problem with that: Apparently gdb does not throw the error for every executable, but only for those linked against gio. Wouldn't that indicate that gio is at least involved in that error?
btw: the error doesn't happen straight away. if the program detects an error with its commandline parameters (and doesn't get to the point where GIO is initialised) then no error. so that means that it's something that is *happening* that is the problem. could be related to the dlopen() of libgvfs...?
(In reply to comment #3) > One problem with that: > Apparently gdb does not throw the error for every executable, but only for > those linked against gio. Wouldn't that indicate that gio is at least involved > in that error? Wouldn't the fact that the executables run fine outside of gdb indicate that gdb is at least involved in that error? I mean, gdb support for threading breaks *all the time*... Also, you didn't really try against *every* executable, and it doesn't make sense that the problem would actually be localized to gio; gio does not make any pthread calls directly, and in fact, it doesn't even call g_thread_create() directly; it only uses it via GThreadPool, which is in *libglib*. So if GResolver's behavior really did require a -pthread to be added, then it ought to be needed in glib-2.0.pc too (or instead), which would break the entire point of the glib/gthread separation, which has been working fine for years... (Alternative hypothesis; your libgio is linked against some optional dependency library that *does* use libpthread directly?)
(In reply to comment #4) > so that means that it's something that is *happening* that is the problem. > could be related to the dlopen() of libgvfs...? ahh... dlopening libpthread into an unthreaded program is forbidden on some platforms, though not linux. but maybe gdb doesn't cope with it? (or maybe it's supposed to, but it recently broke, or else something changed in glibc and gdb hasn't caught up). although it looks like it's basically just an accident that libgvfsdbus is linking against pthread anyway... it gets linked with the same $GLIB_LIBS as the daemons, which include gthread, which the daemons need and the library doesn't. -> gvfs ?
i agree. unless the gvfs backend is calling g_thread_init() for itself (it isn't) then it should not be linked against gthread.
this just got much worse. gvfs pulls in pthread via dbus as well. unless we make significant changes to dbus (or stop using it), then that's not going to go away. with dbus having mandatory -pthread, this bug is starting to look like "any application that might ever end up linking to dbus directly or indirectly needs -pthread up front" which is starting to look like "consider adding -pthread to gio pkg-config" again...
Ah. I get this error from my gdb randomly. Like, trying to start vte under gdb terminates with this error say 4 out of 5 times.
I'd also like to point out my rants in bug 587090 comment 1. Those are not directly related to this issue but point out problems one can get with async gvfs operations in threaded/non-threaded applications.
The mailing list conversation has come to the conclusion that gmodule is the best place to add this in.
Created attachment 148020 [details] [review] [PATCH] Bug 600141 - Add -pthread to gmodule pkg-config
Just noting that this will essentially mean pango and up will all link to pthread. Not that I mind, strictly speaking.
Behdad: If you can guarantee that no pango module links to libpthread then we could add a gmodule-nothread.pc that pango could use. (If you care) Of course, libgio can give no such guarantees, so pthread will be in all gtk apps anyway.
Patch looks good to me.
(In reply to comment #14) > Behdad: If you can guarantee that no pango module links to libpthread then we > could add a gmodule-nothread.pc that pango could use. (If you care) I can guarantee as much, yes.
Comment on attachment 148020 [details] [review] [PATCH] Bug 600141 - Add -pthread to gmodule pkg-config 983a717..5d97ea2 master -> master Behdad: do you want me to make a no-threads version?
(In reply to comment #17) > (From update of attachment 148020 [details] [review]) > 983a717..5d97ea2 master -> master > > Behdad: do you want me to make a no-threads version? Since there's also a gmodule-no-export-2.0 (which is what pango uses), this will start to look like combinatorial explosion. Lets skip it for now.
Ok.