Bug 4475

Tim, please go ahead with your pthread autoconf shopping.

*** Bug 6864 has been marked as a duplicate of this bug. ***

*** Bug 4679 has been marked as a duplicate of this bug. ***

Ok, will do, though it's going to be harder for me to test right now than it
would have been last year -- I don't have convenient access to OSF1 / Tru64 UNIX
right now, and that's one of the platforms that exhibit this problem.

I'll start looking for good pthread checks in GNOME packages, and update this
bug this weekend.

I spent a little time looking, and glib has a lengthy set of checks to find the
necessary flags and libraries for thread support.  Those checks might be
overkill for cairo, but they're certainly well-tested and robust.

I'm looking at glib-2.10.2/configure.in starting with

  g_thread checks

and continuing all the way down to

  AC_MSG_CHECKING(thread related libraries)

Those checks could be incorporated into cairo with some work (they could
probably be pared down a bit).

This brings up a question, though.  glib supports more threading models than
just POSIX threads.  Would it make any sense to (some day) have cairo use
gthreads instead of using POSIX threads directly?

*** Bug 7744 has been marked as a duplicate of this bug. ***

*** Bug 9082 has been marked as a duplicate of this bug. ***

Just a reminder: the configure check also needs to discover how to correctly link to pthread.

My current understanding is that:

1) Header check is needed, obviously, since we include it.

2) We don't want to link to pthread.  Not on Linux.

3) We do want to make sure we can link a test program using pthread symbols.  On Linux, glibc provides weak version of those symbols.

If 3 fails, most probably we don't want pthread, since it most probably means there are native mutexes available.  We may want to make --enable-pthread=yes try -lpthread if 3 fails.

Apart from detection, I think configure should also be tweaked to have a proper default value, so that eg on windows pthread is not even tested unless one really knows what he is doing and specifies --enable-pthread.


# by default disable pthreads on platforms with native threads
AC_ARG_ENABLE(pthread,
  AS_HELP_STRING([--disable-pthread],
		 [Do not use pthread]),
  [use_pthread=$enableval],
  [case "$host" in
    *-*-mingw*)
      use_pthread=no
      ;;
    *-*-beos)
      use_pthread=no
      ;;
    *-*-os2)
      use_pthread=no
      ;;
    *)
      use_pthread=auto
      ;;
    esac
  ])

As an extra complication we only want pthread-stubs for the library, but may want to use a real pthreads for multi-threaded testing.

gmodule is moving towards linking to pthreads by default.  Maybe we can do the same....

The header-only pthread check was already removed two years ago:

commit e3b2212bc5c4884eab356ae263b8318e10c379ac
Author: Benjamin Otte <otte@redhat.com>
Date:   Thu May 13 15:14:29 2010 +0200

    build: Fix pthread detection
    
    Incorporate the pthread detection code from the autoconf archive. Should
    fix build on obscure archs that pretend to be UNIXy - like Mac OS X
    Tiger.
    
    http://www.gnu.org/software/autoconf-archive/
    http://www.gnu.org/software/autoconf-archive/ax_pthread.html

Later on, that was improved again:

commit fca8977219b857e2e61dd86ac39ae9f40086f306
Author: M Joonas Pihlaja <jpihlaja@cc.helsinki.fi>
Date:   Sun Jun 27 03:03:17 2010 +0300

    build: Rework pthread detection.
    
    Use two levels of pthread support: a minimal level used to
    build cairo itself, and a full level to build threaded apps
    which want to use cairo.  The minimal level tries to use
    pthread stubs from libc if possible, but falls back to the
    full level if that's not possible.  We use CFLAGS=-D_REENTRANT
    LIBS=-lpthread to find a real pthread library since that seems
    to work on every unix-like test box we can get our hands on.

This should be more than enough to consider this bug fixed.