configure.ac: Link PSPPIRE explicitly against gthread.
authorBen Pfaff <blp@cs.stanford.edu>
Sat, 5 May 2012 04:30:49 +0000 (21:30 -0700)
committerBen Pfaff <blp@cs.stanford.edu>
Sat, 5 May 2012 17:01:02 +0000 (10:01 -0700)
commit4d24ceb787e6e53bd76ef9006c7f73e975dda140
tree6b0a397f39a6e2fa49817b7d6e5442f20d1587d0
parent78616e13d5fed640d83c0b5b19507129c4c21690
configure.ac: Link PSPPIRE explicitly against gthread.

Seems to be required on OpenSUSE.

PSPPIRE does not make explicit use of threads, but it does use
GTimer.  Thus, it calls g_thread_init() 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 seems to imply that PSPPIRE should call
g_thread_init() before g_timer_new(), or the timer might be
unreliable because Glib would call it later for us.  But the
documentation doesn't seem entirely clear.

Reported by Mindaugas.
Bug #36396.
configure.ac
src/ui/gui/automake.mk