Created attachment 64220 [details] [review]
Patch fixing the problem

Of course, this is only a workaround, because the pthread check in configure is not perfect; so tackling that might be a better solution.

Thanks for the patch.

I'd agree that fixing the pthread check in configure.ac is better than hacking around it in pixman-compiler.h. 

Also, it's usually better to send patches to the mailing list at pixman@lists.freedesktop.org than attaching them to a bugzilla bug.

Actually, I've just looked at the behavior on NetBSD again and saw that
1. on -current, TLS is supported, so the configure script doesn't get to the setspecific part
2. if I disable that part of the configure script manually, I get:
checking for pthread_setspecific... yes

I've asked a MirBSD developer to look at the MirBSD failure again.

Any news here? Otherwise, I'm going to close this bug.

I am working on it. It has been low on my priorities list but thanks for reminding me ;) I'll get back to you soon.

Created attachment 68365 [details] [review]
proposed patch (v2)

Here is the patch (see attached). Rationale and explication:

On MirBSD, the compiler produces a (harmless) warning when the compiler is called without the standard CFLAGS:

foo.c:0: note: someone does not honour COPTS correctly, passed 0 times

However, PIXMAN_LINK_WITH_ENV considers _any_ output on stderr as an error, even if the exit status of the compiler is 0. Furthermore, it resets CFLAGS and LDFLAGS at the start. On MirBSD, this will lead to a warning in each test, making all such tests fail. In particular, the pthread_setspecific test fails, thus pixman is compiled without thread support. This leads to compile errors later on, or at least it did when I tried this on pkgsrc. Re-adding the saved CFLAGS, LDFLAGS and LIBS before the test makes it work.

The second hunk inverts the order of the pthread flag checks. On BSD systems (this is true at least on OpenBSD and MirBSD), both -lpthread and -pthread work but the latter is "preferred", whatever this means.

Thanks for the patch. As mentioned in comment 3, it's better to send patches to the mailing list instead of attaching them to bugzilla.

Please use 'git format-patch' or 'git send-email' for this.

That way, (a) more people can review it, (b) the patch comes with a commit message, and (c) it is easier for us to push it to master.