Re: [debian-hurd-Patches][310474] gconf2 configure hangs
[EMAIL PROTECTED] a écrit : Patches item #310474, was opened at 30/12/2007 23:16 Status: Open Priority: 3 Submitted By: Samuel Thibault (sthibaul-guest) Assigned to: Nobody (None) Summary: gconf2 configure hangs Category: None Group: None Resolution: None Initial Comment: When configuring gconf2 stuff, gconftool-2 hangs on fflush, apparently because there is no stdout, as the attached workaround suggests. Unfortunately, I couldn't reproduce the behavior with self-made programs. We've got the same problem on GNU/kFreeBSD. It started a few months ago with one of the new versions. A bisect showed that the change that has triggered the bug is a call to g_thread_init(). The part to revert is in the patch below. However, even if this fixes the bug, I am almost sure that it is the wrong patch. I also haven't been able to reproduce it easily. The problem only occurs when gconftool-2 is called from the python script called from dpkg. --- gconf-2.20.1.orig/gconf/gconf-sanity-check.c +++ gconf-2.20.1/gconf/gconf-sanity-check.c @@ -43,7 +43,7 @@ GOptionContext *context; GError *error; - g_thread_init (NULL); +// g_thread_init (NULL); context = g_option_context_new (_(- Sanity checks for GConf)); g_option_context_add_group (context, gtk_get_option_group (TRUE)); only in patch2: unchanged: --- gconf-2.20.1.orig/gconf/gconftool.c +++ gconf-2.20.1/gconf/gconftool.c @@ -555,7 +555,7 @@ bindtextdomain (GETTEXT_PACKAGE,GCONF_LOCALE_DIR); textdomain (GETTEXT_PACKAGE); - g_thread_init (NULL); +// g_thread_init (NULL); _gconf_init_i18n (); -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
www.banking-financial.com
Please see this site in Subject
Re: pthread_atfork()
On Tue, 2008-01-01 at 04:10 +, Samuel Thibault wrote: Thomas Bushnell BSG, le Thu 27 Dec 2007 18:06:39 -0800, a écrit : Now, that said, we'd have to modify libc's gnu/stubs.h to also include a gnu/stubs-pthread.h provided by the hurd's libpthread. Yes, certainly, or at least a general Hurdish one or something. Actually, only libpthread provides standard functions that may be stubs. So, something like this? Perhaps, but I would urge you to check with Roland explicitly about this.
www.bankingplans.com
Please see this site in Subject
xpdf
Hey folks, xpdf seems to build OK if you add -lpthreads to LDFLAGS in xpdf/Makefile.in. (And thanks to Ben :-) ) I don't know that it is a portable solution for other architectures though. Thanks, Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xpdf
Samuel Thibault, le Wed 02 Jan 2008 03:33:25 +, a écrit : Barry deFreese, le Tue 01 Jan 2008 22:00:01 -0500, a écrit : xpdf seems to build OK if you add -lpthreads to LDFLAGS in xpdf/Makefile.in. (And thanks to Ben :-) ) Erf, so again that problem with the pthread stubs that are missing from libc... I was wondering: since we had to set _dl_dynamic_weak to 1; in order to get the X11 stubs working properly anyway, maybe we could add to the debian glibc package a temporary patch that implements the few stubs, instead of erroneously asking packages to add -lpthread? Note: of course that's not a proper fix, and it will break if we let _dl_dynamic_weak go back to 0. On the long run, we should have stubs in libc that properly call pthread functions if needed. But the thing is we have an easy way to have things working the same way as on the long run from the point of view of applications. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
