Bug 606523

This also causes mapnik to fail.

http://koji.fedoraproject.org/koji/watchlogs?taskID=2293349

scons: Configure: Checking for C library m... 
.sconf_temp/conftest_4.c <-
  |
  |
  |#include "math.h"
  |
  |int
  |main() {
  |  
  |return 0;
  |}
  |
gcc -o .sconf_temp/conftest_4.o -c -Iinclude -I. -I/usr/local/include -I/usr/include -I/usr/include/freetype2 -I/usr/include/libxml2 -I/usr/include/cairomm-1.0 -I/usr/lib64/cairomm-1.0/include -I/usr/include/cairo -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include -I/usr/include/pixman-1 -I/usr/include/libpng12 .sconf_temp/conftest_4.c
gcc -o .sconf_temp/conftest_4 .sconf_temp/conftest_4.o -Lsrc -L/usr/local/lib64 -L/usr/lib64 -lfreetype -lxml2 -lz -lm -lcairomm-1.0 -lcairo -lsigc-2.0 -lm
/usr/lib64/libcairo.so: undefined reference to `pthread_mutexattr_destroy'
/usr/lib64/libcairo.so: undefined reference to `pthread_mutexattr_settype'
/usr/lib64/libcairo.so: undefined reference to `pthread_mutexattr_init'
collect2: ld returned 1 exit status
scons: Configure: no

This should be mostly fixed in cairo-1.9.10-3.fc14. When I've fixed the rpath issue, I'm gonna close this bug.

So it turns out that this is likely a gcc bug, reassigning.

These two builds are involved:
Cairo 1.9.10-3: http://koji.fedoraproject.org/koji/buildinfo?buildID=181566
Cairo 1.9.10-2: http://koji.fedoraproject.org/koji/buildinfo?buildID=181551
(I only checked x86_64, not sure if it's a problem for i686, too.)

The later one has a workaround patch applied to do the linking with gcc instead of g++ and therefor works. (This works because automake erroneously thinks it needs to use g++ for linking while it does not need to do so.)


Anyway, the problem:
When linking libcairo.so with -pthread using g++, the resulting library will not link to libpthread. It works when using gcc instead or when using gcc from F13.

Steps to reproduce:
- Build Cairo 1.9.10-2 and run ldd on the resulting libcairo.so.2.10910.0.
Expected result:
- The lib is linked to libpthread.
Actual result:
- It is not.

I suspect this is easy to reproduce using g++ simple.c -pthread and expecting the resulting binary, but I couldn't try that easily as I don't run rawhide.

The only difference between f13 and f14 gcc is that in f14 static libstdc++.a (and a few other *.a libraries) have been split into *-static subpackages, nothing else.

Just tried a simple testcase in F14 mock buildroot and it works just fine.  So, if you suspect a gcc problem, please come up with a real testcase.  You can pass -v to gcc (or g++) to see what exactly is passed to the linker.

This should be fixed in cairo-1.9.12-1.fc14