Re: [PATCH] configure.ac: Link PSPPIRE explicitly against gthread.

[Ben Pfaff]

Thanks.

I added those details to the commit message and pushed the fix.

John Darrington <address@hidden> writes:

> OK.  I agree that the documentation is not easy to follow, but it
> seems that calling g_thread_init cannot do any harm so long as
> we do it early.
>
> On Fri, May 04, 2012 at 11:16:02PM -0700, Ben Pfaff wrote:
>      I added a call in the same commit that adds a call to
>      g_timer_new() to main(), because of the following note in the
>      documentation for GTimer:
>      
>          GTimer uses a higher-quality clock when thread support is
>          available.  Therefore, calling g_thread_init() while timers
>          are running may lead to unreliable results.  It is best to
>          call g_thread_init() before starting any timers, if you are
>          using threads at all.
>      
>      Separately, the documentation for threads in Glib says:
>      
>          Calling g_thread_init() with a NULL argument is somewhat more
>          relaxed.  You may call any other glib functions in the main
>          thread before g_thread_init() as long as g_thread_init() is
>          not called from a glib callback, or with any locks held.
>          However, many libraries above glib does not support late
>          initialization of threads, so doing this should be avoided if
>          possible.
>      
>          Please note that since version 2.24 the GObject
>          initialization function g_type_init() initializes threads
>          (with a NULL argument), so most applications, including those
>          using Gtk+ will run with threads enabled.  If you want a
>          special thread implementation, make sure you call
>          g_thread_init() before g_type_init() is called.
>      
>      Taken together, it seemed to imply that I should call
>      g_thread_init() before g_timer_new(), or the timer might be
>      unreliable because glib would call it later for me.  But the
>      documentation doesn't seem entirely clear to me.
>      
>      John Darrington <address@hidden> writes:
>      
>      > This looks fine to me.
>      >
>      > However, I feel obliged to ask the question why are we actually
>      > calling g_thread_init.  The docs say this is necessary iff we are
>      > calling GLib from more than one thread.  So far as I'm aware, we're
>      > not doing that, are we?
>      >
>      > J'
>      >
>      > On Fri, May 04, 2012 at 09:33:32PM -0700, Ben Pfaff wrote:
>      >      Seems to be required on OpenSUSE.
>      >      
>      >      Reported by Mindaugas.
>      >      Bug #36396.
>      >      ---
>      >       configure.ac           |    3 +++
>      >       src/ui/gui/automake.mk |    1 +
>      >       2 files changed, 4 insertions(+), 0 deletions(-)
>      >      
>      >      diff --git a/configure.ac b/configure.ac
>      >      index 7d33ca2..2f3a8da 100644
>      >      --- a/configure.ac
>      >      +++ b/configure.ac
>      >      @@ -73,6 +73,9 @@ AC_ARG_WITH([gui],
>      >       AM_CONDITIONAL([HAVE_GUI], 
>      >                      [test "$with_cairo" != no && test "$with_gui" != 
> "no"])
>      >       if test "$with_cairo" != no && test "$with_gui" != "no"; then
>      >      +  PKG_CHECK_MODULES([GTHREAD], [gthread-2.0], [],
>      >      +    [PSPP_REQUIRED_PREREQ([gthread 2.0 (or use --without-gui)])])
>      >      +
>      >         PKG_CHECK_MODULES([GTK], [gtk+-2.0 >= 2.16], [],
>      >           [PSPP_REQUIRED_PREREQ([gtk+ 2.0 version 2.16 or later (or 
> use --without-gui)])])
>      >       
>      >      diff --git a/src/ui/gui/automake.mk b/src/ui/gui/automake.mk
>      >      index 96209a0..a7cb1de 100644
>      >      --- a/src/ui/gui/automake.mk
>      >      +++ b/src/ui/gui/automake.mk
>      >      @@ -74,6 +74,7 @@ src_ui_gui_psppire_LDADD = \
>      >        src/libpspp.la \
>      >        src/libpspp-core.la \
>      >        $(GTK_LIBS) \
>      >      + $(GTHREAD_LIBS) \
>      >        $(GTKSOURCEVIEW_LIBS) \
>      >        $(CAIRO_LIBS) \
>      >        $(LIBINTL) \
>      >      -- 
>      >      1.7.2.5
>      >      
>      >      
>      >      _______________________________________________
>      >      pspp-dev mailing list
>      >      address@hidden
>      >      https://lists.gnu.org/mailman/listinfo/pspp-dev