Bug 9449

Summary: make check fails on Solaris, pdf2png, svg2png multiple link against libcairo.so
Product: cairo Reporter: Tim Mooney <Tim.Mooney>
Component: generalAssignee: Carl Worth <cworth>
Status: RESOLVED WONTFIX QA Contact: cairo-bugs mailing list <cairo-bugs>
Severity: minor    
Priority: high    
Version: 1.3.10   
Hardware: SPARC   
OS: Solaris   
Whiteboard:
i915 platform: i915 features:

Description Tim Mooney 2006-12-25 18:54:33 UTC
When running make check in the test directory of either 1.3.10 or 1.2.6 on
x86_64-sun-solaris2.10 and vendor toolchain (Sun compilers and linker), ld fails
to link pdf2png.  It's unhappy because it's determined that libcairo.so.2 gets
linked to twice, and for reasons known only to the Solaris developers, that's
more than just a warning, it's an error.

/bin/bash ../libtool --tag=CC --mode=link cc  -Xa -xO2 -xstrconst -KPIC -mt
-xtarget=native -xarch=amd64 -I/local/include -I/local/gnu/include 
-L/local/lib/64 -L/local/gnu/lib/64 -o pdf2png  pdf2png-pdf2png.o
libcairotest.la ../test/pdiff/libpdiff.la ../boilerplate/libcairoboilerplate.la
../src/libcairo.la -lpthread -R/usr/openwin/lib -L/local/gnu/lib/64
-L/local/lib/64 -L/usr/openwin/lib -lpoppler-glib -lpoppler -lgtk-x11-2.0
-lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo
-lSM -lICE -lsocket -lnsl -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl
-lfreetype -lz -lfontconfig -lglitz -lm -lpng12 -lXrender -lX11   -lm
cc -Xa -xO2 -xstrconst -KPIC -mt -xtarget=native -xarch=amd64 -I/local/include
-I/local/gnu/include -o .libs/pdf2png pdf2png-pdf2png.o  -L/local/lib/64
-L/local/gnu/lib/64 ./.libs/libcairotest.a ../test/pdiff/.libs/libpdiff.a
../boilerplate/.libs/libcairoboilerplate.a -L/usr/openwin/lib
/local/lib/64/libglitz-glx.so -L/usr/X11/lib/64 -L/local/lib/64/X11 -lGL
../src/.libs/libcairo.so -L/usr/openwin/lib/64 -lpthread
/local/gnu/lib/64/libpoppler-glib.so /local/gnu/lib/64/libpoppler.so -ljpeg
/local/gnu/lib/64/libgtk-x11-2.0.so /local/gnu/lib/64/libgdk-x11-2.0.so
/local/gnu/lib/64/libatk-1.0.so /local/gnu/lib/64/libgdk_pixbuf-2.0.so
/local/gnu/lib/64/libpangocairo-1.0.so /local/gnu/lib/64/libpangoft2-1.0.so
/local/gnu/lib/64/libpango-1.0.so /local/lib/64/libcairo.so -lSM -lICE -lsocket
-lnsl /local/gnu/lib/64/libgobject-2.0.so /local/gnu/lib/64/libgmodule-2.0.so
/local/gnu/lib/64/libglib-2.0.so -lrt /local/gnu/lib/64/libintl.so -lc
/local/lib/64/libfontconfig.so /local/lib/64/libfreetype.so
/local/lib/64/libexpat.so /local/lib/64/libglitz.so /local/lib/64/libpng12.so
-lz /local/lib/64/libXrender.so -lX11 -lm -R/local/lib/64 -R/local/gnu/lib/64
-R/usr/openwin/lib
ld: fatal: recording name conflict: file `../src/.libs/libcairo.so' and file
`/local/lib/64/libcairo.so' provide identical dependency names: libcairo.so.2 
(possible multiple inclusion of the same file)
ld: fatal: File processing errors. No output written to .libs/pdf2png
gmake[2]: *** [pdf2png] Error 1


The same issue happens for svg2png.  Since many of the later tests depend on
those two programs, it's not possible to tell how many of the later tests
actually pass and how many fail.

IMHO none of this is cairo's fault, it's the fault of the linker generating an
error when it should probably only generate a warning.  Still, I thought I
should report it.

I suppose it would be possible to work around this unfortunate behavior by
generating a library that has all the same object files as ../src/libcairo.la
but has a different name (e.g. ./libcairo-tests.la) and then linking all the
tests against that instead of ../src/libcairo.la, but I don't know how easy or
hard that is to do.  I see now that there already is a libcairotest.la -- maybe
it would be possible to include all the other object files in that same library?
Comment 1 Chris Wilson 2008-10-10 09:12:52 UTC
Hmm, I thought this might have been fixed by Behdad's library reversioning... But it's complaining about the soname.major.

I do sympathise with you that you cannot build the test suite correctly (and please know that I do want as many people on as many varied systems as possible to run the test suite!). But that just seems an ugly work-around for a linker issue and introduces another step that can cause confusion and subtle issues.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.