Bug 606523 - linking issues
linking issues
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: cairo (Show other bugs)
rawhide
All Linux
high Severity medium
: ---
: ---
Assigned To: Benjamin Otte
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 600010
  Show dependency treegraph
 
Reported: 2010-06-21 16:44 EDT by Orion Poplawski
Modified: 2010-07-13 18:21 EDT (History)
4 users (show)

See Also:
Fixed In Version: cairo-1.9.12-1.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-13 18:21:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Orion Poplawski 2010-06-21 16:44:49 EDT
Description of problem:

Looks like cairo has some linking issues:

mock-chroot> rpmlint cairo
cairo.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcairo.so.2.10908.0 pthread_mutexattr_settype
cairo.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcairo.so.2.10908.0 pthread_mutexattr_destroy
cairo.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcairo.so.2.10908.0 pthread_mutexattr_init
cairo.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcairo.so.2.10908.0 /usr/lib64/libstdc++.so.6
cairo.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcairo-script-interpreter.so.2.10908.0 /usr/lib64/libpixman-1.so.0
cairo.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcairo-script-interpreter.so.2.10908.0 /usr/lib64/libpng12.so.0
cairo.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcairo-script-interpreter.so.2.10908.0 /usr/lib64/libXrender.so.1
cairo.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcairo-script-interpreter.so.2.10908.0 /usr/lib64/libX11.so.6
cairo.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/libcairo-script-interpreter.so.2.10908.0 ['/usr/lib64']

This is causing my plplot build to fail with:

/usr/lib64/ccache/gcc  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic    CMakeFiles/ext-cairo-test.dir/ext-cairo-test.c.o  -o ext-cairo-test -rdynamic -lcairo ../../src/libplplotd.so.9.8.0 -lltdl -ldl ../../lib/csa/libcsirocsa.so.0.0.1 ../../lib/nn/libcsironn.so.0.0.1 -lqhull ../../lib/qsastime/libqsastime.so.0.0.1 -lm -lfreetype -Wl,-rpath,/builddir/build/BUILD/plplot-5.9.6/fedora/src:/builddir/build/BUILD/plplot-5.9.6/fedora/lib/csa:/builddir/build/BUILD/plplot-5.9.6/fedora/lib/nn:/builddir/build/BUILD/plplot-5.9.6/fedora/lib/qsastime 
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../lib64/libcairo.so: undefined reference to `pthread_mutexattr_settype'
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../lib64/libcairo.so: undefined reference to `pthread_mutexattr_destroy'
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../lib64/libcairo.so: undefined reference to `pthread_mutexattr_init'
collect2: ld returned 1 exit status

Version-Release number of selected component (if applicable):
cairo-1.9.8-1.fc14.x86_64
Comment 1 Christopher Brown 2010-07-03 21:57:11 EDT
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
Comment 2 Benjamin Otte 2010-07-04 20:48:11 EDT
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.
Comment 3 Benjamin Otte 2010-07-05 11:27:43 EDT
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.
Comment 4 Jakub Jelinek 2010-07-05 12:00:02 EDT
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.
Comment 5 Benjamin Otte 2010-07-13 18:21:05 EDT
This should be fixed in cairo-1.9.12-1.fc14

Note You need to log in before you can comment on or make changes to this bug.