I've used the following in my paludis bashrc as a quick fix. It's /bad/ style, I do not propose this as a general fix, it needs to be improved upon. A general fix for all archs would need to properly determine the endianess instead of hardcoding it, like it does now for gcc. Also "-lpthread" should not be passed using LDFLAGS. These were the only modifications I needed on AMD64 to successfully compile cairo with clang and clang+lto, no further patches were needed. case "${CATEGORY}/${PN}" in x11-libs/cairo) EXTRA_ECONF="ax_cv_c_float_words_bigendian=no" LDFLAGS="${LDFLAGS} -lpthread" ;; esac Reproducible: Always
1) Please post your `emerge --info' (or equivalent) output in a comment. 2) Please attach the entire build log to this bug report.
Created attachment 344866 [details] build log - float endianess test fails in configure with clang -O4 Actually the float endianess configure test fails only using clang -O4 It's reproducable on x86 and amd64, both archs quit the test with checking whether float word ordering is bigendian... unknown configure: error: Unknown float word ordering. You need to manually preset ax_cv_c_float_words_bigendian=no (or yes) according to your system. clang -O2 is not affected. I've changed the bug title to reflect this. It's an lto related bug, as clang -O4 implies -flto. If you do not want to fix it, that's fine, I've been informed that using LTO is still experimental.
Created attachment 344868 [details] build log - linking fails with symbols from pthread missing with clang -O4 Subsequently, linking pthread explicitly is (also) only needed if -O4 is used, see attachment. Using clang -O2 there is no breakage at link time, regardless of whether bfd or gold is used.
The problem is that clang -O2 -c -o obj input.c produces ELF objects while clang -O4 -c -o obj input.c outputs an object file in bitcode format. The AC test for float endianess however is expecting an ELF object file to grep the string representation (seesnoon or noonsees) of a special double value, like this 00000000 7f 45 4c 46 01 01 01 03 00 00 00 00 00 00 00 00 |.ELF............| 00000010 01 00 03 00 01 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 7c 00 00 00 00 00 00 00 34 00 00 00 00 00 28 00 ||.......4.....(.| 00000030 08 00 05 00 00 00 00 00 73 65 65 73 6e 6f 6f 6e |........seesnoon| 00000040 00 2e 74 65 78 74 00 2e 62 73 73 00 2e 6e 6f 74 |..text..bss..not| 00000050 65 2e 47 4e 55 2d 73 74 61 63 6b 00 2e 73 68 73 |e.GNU-stack..shs| 00000060 74 72 74 61 62 00 2e 73 74 72 74 61 62 00 2e 73 |trtab..strtab..s| 00000070 79 6d 74 61 62 00 2e 64 61 74 61 00 00 00 00 00 |ymtab..data.....| 00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * [...] In comparison the bitcode representation for reference: 00000000 42 43 c0 de 21 0c 00 00 8d 00 00 00 0b 82 20 00 |BC..!......... .| 00000010 02 00 00 00 12 00 00 00 07 81 23 91 41 c8 04 49 |..........#.A..I| 00000020 06 10 32 39 92 01 84 0c 25 05 08 19 1e 04 8b 62 |..29....%......b| 00000030 80 0c 45 02 42 92 0b 42 64 10 32 14 38 08 18 49 |..E.B..Bd.2.8..I| 00000040 0a 32 44 24 48 0a 90 21 23 c4 52 80 0c 19 21 72 |.2D$H..!#.R...!r| 00000050 24 07 c8 c8 10 62 a8 a0 a8 40 c6 f0 01 00 00 00 |$....b...@......| 00000060 89 20 00 00 0a 00 00 00 32 22 c8 08 20 64 85 04 |. ......2".. d..| 00000070 93 21 a4 84 04 93 21 e3 84 a1 90 14 12 4c 86 8c |.!....!......L..| 00000080 0b 84 64 4c 10 18 43 00 84 39 02 84 94 01 23 02 |..dL..C..9....#.| 00000090 13 a2 74 98 03 3c b0 83 36 80 87 71 68 03 76 48 |..t..<..6..qh.vH| 000000a0 07 77 a8 07 7c 68 83 73 70 87 7a d8 30 12 e5 d0 |.w..|h.sp.z.0...| 000000b0 06 f0 a0 07 73 20 07 7a 30 07 72 a0 07 73 20 07 |....s .z0.r..s .| 000000c0 6d 90 0e 71 a0 07 78 a0 07 78 d0 06 e9 80 07 7a |m..q..x..x.....z| 000000d0 80 07 7a 80 07 6d 90 0e 71 60 07 7a 10 07 76 a0 |..z..m..q`.z..v.| 000000e0 07 71 60 07 6d 90 0e 73 20 07 7a 30 07 72 a0 07 |.q`.m..s .z0.r..| 000000f0 73 20 07 6d 90 0e 76 40 07 7a 30 07 72 a0 07 76 |s .m..v@.z0.r..v| 00000100 40 07 6d 60 0e 73 20 07 7a 30 07 72 a0 07 73 20 |@.m`.s .z0.r..s | 00000110 07 6d 60 0e 76 40 07 7a 30 07 72 a0 07 76 40 07 |.m`.v@.z0.r..v@.| 00000120 6d 60 0f 76 40 07 7a 60 07 74 a0 07 76 40 07 6d |m`.v@.z`.t..v@.m| 00000130 60 0f 71 20 07 78 a0 07 71 20 07 78 a0 07 71 20 |`.q .x..q .x..q | 00000140 07 78 d0 06 e1 00 07 7a 00 07 7a 60 07 74 d0 06 |.x.....z..z`.t..| 00000150 e6 80 07 70 a0 07 73 20 07 7a 30 07 72 d0 06 ee |...p..s .z0.r...| 00000160 80 07 7a 10 07 76 a0 07 73 20 07 6d 30 0b 71 20 |..z..v..s .m0.q | 00000170 07 78 b0 a2 61 07 76 b0 87 76 70 83 76 28 07 7a |.x..a.v..vp.v(.z| 00000180 08 07 72 08 07 7a 08 07 9d 07 32 24 90 11 22 43 |..r..z....2$.."C| 00000190 02 63 00 62 15 82 59 20 09 00 00 00 32 1e 98 0c |.c.b..Y ....2...| 000001a0 19 11 4c 90 8c 09 26 47 c6 04 43 c2 18 c1 bc e6 |..L...&G..C.....| 000001b0 aa 9d e7 ed bb ef bc 41 b3 0d 00 11 83 01 00 00 |.......A........| 000001c0 79 18 00 00 17 00 00 00 33 08 80 1c c4 e1 1c 66 |y.......3......f| 000001d0 14 01 3d 88 43 38 84 c3 8c 42 80 07 79 78 07 73 |..=.C8...B..yx.s| 000001e0 98 71 0c e6 00 0f ed 10 0e f4 80 0e 33 0c 42 1e |.q..........3.B.| 000001f0 c2 c1 1d ce a1 1c 66 30 05 3d 88 43 38 84 83 1b |......f0.=.C8...| 00000200 cc 03 3d c8 43 3d 8c 03 3d cc 78 8c 74 70 07 7b |..=.C=..=.x.tp.{| 00000210 08 07 79 48 87 70 70 07 7a 70 03 76 78 87 70 20 |..yH.pp.zp.vx.p | 00000220 07 00 00 00 71 20 00 00 04 00 00 00 06 10 0c 16 |....q ..........| 00000230 90 2c 4b c5 f8 94 44 0c 00 00 00 00 00 00 00 00 |.,K...D.........| 00000240 input.c listing: double d __attribute__((used)) = 90904234967036810337470478905505011476211692735615632014797120844053488865816695273723469097858056257517020191247487429516932130503560650002327564517570778480236724525140520121371739201496540132640109977779420565776568942592.0;
Created attachment 344902 [details, diff] /etc/portage/patches/x11-libs/cairo/cairo-1.12.12-make-ac-float-endianess-test-llvm-bitcode-save.patch This patch ensures that eventually compiler-dependent intermediate representations of object files are translated down to native code. This in turn is needed to make the AC test for float endianess work in scenarios where the intermediate representation is not ELF. This should be a proper fix for the problem in attachment #344866 [details] and might be pushed upstream if need be.
Concerning the pthread issue: EXTRA_ECONF="--enable-pthread=yes" does the trick, no passing via LDFLAGS necessary. If above configure option is not passed the default is "auto" instead of "yes", which basically does 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. have_pthread="no" if test "x$enable_pthread" != "xyes"; then CAIRO_CHECK_PTHREAD( [pthread], [-D_REENTRANT], [], [libcairo_pthread_program], [have_pthread=yes], []) fi dnl Default to using the real pthreads for libcairo. if test "x$have_pthread" != "xyes"; then have_pthread="$have_real_pthread"; pthread_CFLAGS="$real_pthread_CFLAGS"; pthread_LIBS="$real_pthread_LIBS"; fi -- >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 does not work if clang -O4 is in use There is more than one option to solve this, I suppose: - always --enable-pthread=yes in the ebuild - introduce a threads use flag in the ebuild - 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 succeeds As I do not know which route to pick and since this is within preference of the maintainer(s), I'll plead for them to cherry pick one that fits best. Thanks
Please submit patches to upstream's bug tracker or mailing list so they can be reviewed.
Comment on attachment 344866 [details] build log - float endianess test fails in configure with clang -O4 Weird, FF20 or the bug tracker corrupts gzip attachment downloads here if mimetype is set to "application/gzip" (auto-detected!) or "application/x-gzip". application/octet-stream or fetching the file with wget works.
This is an LTO issue with GCC-4.7 ~amd64 as well. Using -flto & -fuse-linker-plugin with -Wl,--gc-sections is also triggering a similar error for me. Seems to build fine without it because the -lpthread flag is added. Below is a comparison of the problematic linker line. With -flto libtool: link: x86_64-pc-linux-gnu-gcc -march=native -O2 -fdata-sections -ffunction-sections -flto -fomit-frame-pointer -fpredictive-commoning -ftree-vectorize -fuse-linker-plugin -pipe -Wl,-O1 -Wl,--gc-sections -o .libs/cairo-analyse-trace cairo-analyse-trace.o cairo-error.o -Wl,--as-needed ../util/cairo-script/.libs/libcairo-script-interpreter.so -llzo2 ../util/cairo-missing/.libs/libcairo-missing.a ./.libs/libcairoperf.a ../boilerplate/.libs/libcairoboilerplate.a /var/tmp/portage/x11-libs/cairo-1.12.14-r4/work/cairo-1.12.14/src/.libs/libcairo.so ../src/.libs/libcairo.so -lpixman-1 /usr/lib64/libfontconfig.so -lbz2 -lexpat -lfreetype -lEGL -ldl -lpng15 -lxcb-shm -lxcb-render -lxcb -lXrender -lX11 -lXext -lz -lGL -lrt -lm /var/tmp/portage/x11-libs/cairo-1.12.14-r4/work/cairo-1.12.14/src/.libs/libcairo.so: error: undefined reference to 'pthread_mutexattr_destroy' /var/tmp/portage/x11-libs/cairo-1.12.14-r4/work/cairo-1.12.14/src/.libs/libcairo.so: error: undefined reference to 'pthread_mutexattr_settype' /var/tmp/portage/x11-libs/cairo-1.12.14-r4/work/cairo-1.12.14/src/.libs/libcairo.so: error: undefined reference to 'pthread_mutexattr_init' collect2: error: ld returned 1 exit status make[4]: *** [cairo-analyse-trace] Error 1 make[4]: *** Waiting for unfinished jobs.... /var/tmp/portage/x11-libs/cairo-1.12.14-r4/work/cairo-1.12.14/src/.libs/libcairo.so: error: undefined reference to 'pthread_mutexattr_destroy' /var/tmp/portage/x11-libs/cairo-1.12.14-r4/work/cairo-1.12.14/src/.libs/libcairo.so: error: undefined reference to 'pthread_mutexattr_settype' /var/tmp/portage/x11-libs/cairo-1.12.14-r4/work/cairo-1.12.14/src/.libs/libcairo.so: error: undefined reference to 'pthread_mutexattr_init' collect2: error: ld returned 1 exit status make[4]: *** [cairo-perf-trace] Error 1 /var/tmp/portage/x11-libs/cairo-1.12.14-r4/work/cairo-1.12.14/src/.libs/libcairo.so: error: undefined reference to 'pthread_mutexattr_destroy' /var/tmp/portage/x11-libs/cairo-1.12.14-r4/work/cairo-1.12.14/src/.libs/libcairo.so: error: undefined reference to 'pthread_mutexattr_settype' /var/tmp/portage/x11-libs/cairo-1.12.14-r4/work/cairo-1.12.14/src/.libs/libcairo.so: error: undefined reference to 'pthread_mutexattr_init' collect2: error: ld returned 1 exit status Without LTO libtool: link: x86_64-pc-linux-gnu-gcc -march=native -O2 -fdata-sections -ffunction-sections -fomit-frame-pointer -fpredictive-commoning -ftree-vectorize -pipe -Wl,-O1 -o .libs/cairo-perf-trace cairo-perf-trace.o cairo-error.o cairo-hash.o -Wl,--as-needed ../util/cairo-script/.libs/libcairo-script-interpreter.so -llzo2 ../util/cairo-missing/.libs/libcairo-missing.a ./.libs/libcairoperf.a ../boilerplate/.libs/libcairoboilerplate.a /var/tmp/portage/x11-libs/cairo-1.12.14-r4/work/cairo-1.12.14/src/.libs/libcairo.so ../src/.libs/libcairo.so -lpthread -lpixman-1 /usr/lib64/libfontconfig.so -lbz2 -lexpat -lfreetype -lEGL -ldl -lpng15 -lxcb-shm -lxcb-render -lxcb -lXrender -lX11 -lXext -lz -lGL -lrt -lm libtool: link: x86_64-pc-linux-gnu-gcc -march=native -O2 -fdata-sections -ffunction-sections -fomit-frame-pointer -fpredictive-commoning -ftree-vectorize -pipe -Wl,-O1 -o .libs/cairo-analyse-trace cairo-analyse-trace.o cairo-error.o -Wl,--as-needed ../util/cairo-script/.libs/libcairo-script-interpreter.so -llzo2 ../util/cairo-missing/.libs/libcairo-missing.a ./.libs/libcairoperf.a ../boilerplate/.libs/libcairoboilerplate.a /var/tmp/portage/x11-libs/cairo-1.12.14-r4/work/cairo-1.12.14/src/.libs/libcairo.so ../src/.libs/libcairo.so -lpthread -lpixman-1 /usr/lib64/libfontconfig.so -lbz2 -lexpat -lfreetype -lEGL -ldl -lpng15 -lxcb-shm -lxcb-render -lxcb -lXrender -lX11 -lXext -lz -lGL -lrt -lm
I don't think we're going to fix LTO bugs. At the very minimum, try a new cairo and a new gcc.
