Bug 63310 - x11-libs/cairo-1.12.14 fails to compile using clang+lto
Summary: x11-libs/cairo-1.12.14 fails to compile using clang+lto
Status: NEW
Alias: None
Product: cairo
Classification: Unclassified
Component: general (show other bugs)
Version: 1.12.12
Hardware: All Linux (All)
: medium normal
Assignee: Chris Wilson
QA Contact: cairo-bugs mailing list
Keywords: patch
Depends on:
Reported: 2013-04-09 12:43 UTC by cmuelle8
Modified: 2013-04-12 17:36 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

cairo-1.12.12-make-ac-float-endianess-test-llvm-bitcode-save.patch (1.26 KB, patch)
2013-04-09 12:43 UTC, cmuelle8
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description cmuelle8 2013-04-09 12:43:48 UTC
Created attachment 77662 [details] [review]

I've posted this to bugs.gentoo.org before

As requested there, I repost the patches here. There are two issues I encountered when compiling cairo with "clang -O4":

1) bitcode representation of object files makes float endianess test in configure break (see attached patch)

2) "automatic configuration" of pthreads does not work while explicitly --enable-pthread=yes to configure does

If "--enable-pthread=yes" configure option is not passed, the default is "auto" instead of "yes", which basically runs the first block of the following lines in
  cairo-1.12.12/build/configure.ac.pthread (around line 220)
-- >8 --
    dnl Check if we can use libc's stubs in libcairo.
    dnl Only do this if the user hasn't explicitly enabled
    dnl pthreads, but is relying on automatic configuration.
    if test "x$enable_pthread" != "xyes"; then
            [pthread], [-D_REENTRANT], [],

    dnl Default to using the real pthreads for libcairo.
    if test "x$have_pthread" != "xyes"; then
-- >8 --

This automatic configuration apparently does not work if clang -O4 is used, even though libcairo_pthread_program seems to succeed.

Or in other words: using libc stubs as a pthread provider currently does not work if clang -O4 is in use, the automatically configured stubs make the compile quit with

libtool: link: clang -march=native -pipe -fomit-frame-pointer -O4 -finline-limit=1200 -march=native -pipe -fomit-frame-pointer -O4 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -Wl,-z -Wl,norelro -o .libs/cairo-analyse-trace cairo-analyse-trace.o cairo-error.o  -Wl,--as-needed ../util/cairo-script/.libs/libcairo-script-interpreter.so ../util/cairo-missing/.libs/libcairo-missing.a ./.libs/libcairoperf.a ../boilerplate/.libs/libcairoboilerplate.a /var/tmp/paludis/x11-libs-cairo-1.12.12-r1/work/cairo-1.12.12/src/.libs/libcairo.so ../src/.libs/libcairo.so -lpixman-1 -lfontconfig -lfreetype -lEGL -ldl -lpng15 -lxcb-shm -lxcb-render -lxcb -lXrender -lX11 -lXext -lz -lGL -lOpenVG -lrt -lm
/var/tmp/paludis/x11-libs-cairo-1.12.12-r1/work/cairo-1.12.12/src/.libs/libcairo.so: error: undefined reference to 'pthread_mutexattr_settype'
/var/tmp/paludis/x11-libs-cairo-1.12.12-r1/work/cairo-1.12.12/src/.libs/libcairo.so: error: undefined reference to 'pthread_mutexattr_init'
/var/tmp/paludis/x11-libs-cairo-1.12.12-r1/work/cairo-1.12.12/src/.libs/libcairo.so: error: undefined reference to 'pthread_mutexattr_destroy'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[4]: *** [cairo-analyse-trace] Error 1
make[4]: Leaving directory `/var/tmp/paludis/x11-libs-cairo-1.12.12-r1/work/cairo-1.12.12/perf'
make[3]: Leaving directory `/var/tmp/paludis/x11-libs-cairo-1.12.12-r1/work/cairo-1.12.12/perf'
make[2]: Leaving directory `/var/tmp/paludis/x11-libs-cairo-1.12.12-r1/work/cairo-1.12.12/perf'
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: Leaving directory `/var/tmp/paludis/x11-libs-cairo-1.12.12-r1/work/cairo-1.12.12'
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

I'm unsure about a proper fix for this, but thought about
  - patch configure.ac.pthread to use real_pthread as an automatic configuration
    i.e. throw out libc stubs, use real_pthread if libcairo_pthread_program 


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.