Raimund, Can we use these: http://docs.oracle.com/cd/E18659_01/html/821-1383/gjzmf.html I have your patch in my tree, waiting to see if we can resolve this part. Without correct memory barrier, undefined behavior can result, though, it's only known to happen for Alpha architectures. Thanks, behdad On 13-01-06 09:15 AM, Raimund Steger wrote: > Behdad Esfahbod wrote: >> [...] > >> diff --git a/configure.ac b/configure.ac >> index 5657bb5..fda5650 100644 >> --- a/configure.ac >> +++ b/configure.ac > >> [...] > >> + >> +have_pthread=false >> +if test "$os_win32" = no; then >> + AX_PTHREAD([have_pthread=true]) >> +fi >> +if $have_pthread; then >> + AC_DEFINE(HAVE_PTHREAD, 1, [Have POSIX threads]) >> +fi >> +AM_CONDITIONAL(HAVE_PTHREAD, $have_pthread) > > I was doing some more testing and got coredumps when using FcFontMatch from > multiple threads on Solaris, using GCC as well as Sun Studio (the latter with > atomic operations from atomic.h, see attached -- /experimental/ -- patch -- > which is NO suggestion for the upcoming snapshot release (*) ). > > Then I noticed that -mt or -D_REENTRANT had not been passed to 'cc'. Now this > is a Solaris specialty but I think AX_PTHREAD could do all the work: > > http://www.gnu.org/software/autoconf-archive/ax_pthread.html > > For now I seem to be successful by adding the following in the 'if > $have_pthread' branch above, as suggested by the linked docs: > > LIBS="$PTHREAD_LIBS $LIBS" > CFLAGS="$CFLAGS $PTHREAD_CFLAGS" > CC="$PTHREAD_CC" > > > (*) Solaris atomic operations do not implement a full memory barrier. However, > I'm not sure whether this is a problem for the way fontconfig uses these > operations. So far I've not been able to attribute any coredumps to _this_ > circumstance. This would need attention from an expert on the subject (which > I'm not). > > > Raimund > > > -- behdad http://behdad.org/ _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
