Bug 483408 – =x11-libs/cairo-1.12.16 with sys-devel/clang - /usr/include/libiberty.h:616:12: error: expected parameter declarator extern int asprintf (char **, const char *, ...) ATTRIBUTE_PRINTF_2;

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Stefan de Konink 2013-09-02 16:29:54 UTC]

Cairo seems to raise specific issues with system headers while compiling util/cairo-trace. When I disable the compilation of cairo-trace in its Makefile the build is succesful.

Reproducible: Always

[Comment 1 Jeroen Roovers (RETIRED) 2013-09-04 12:41:20 UTC]

1) Please post your `emerge --info' output in a comment.
2) Please attach the entire build log to this bug report.

[Comment 2 Tom Wijsman (TomWij) (RETIRED) 2013-09-05 10:06:56 UTC]

(In reply to Jeroen Roovers from comment #1)
> 1) Please post your `emerge --info' output in a comment.
> 2) Please attach the entire build log to this bug report.

Please provide the above requested information, thank you.

[Comment 3 Stefan de Konink 2013-09-05 10:42:19 UTC]

Created attachment 357910 [details]
emerge --info

[Comment 4 Stefan de Konink 2013-09-05 10:51:55 UTC]

Created attachment 357914 [details]
build.log

[Comment 5 Austin English (RETIRED) 2014-02-25 21:24:05 UTC]

Still in 3.3

[Comment 6 Alexandre Rostovtsev (RETIRED) 2014-04-20 19:17:48 UTC]

*** Bug 502478 has been marked as a duplicate of this bug. ***

[Comment 7 Fabio Scaccabarozzi 2014-08-09 13:15:28 UTC]

Created attachment 382588 [details, diff]
Remove libiberty include from util/cairo-trace/lookup-symbol.c

[Comment 8 Fabio Scaccabarozzi 2014-08-09 13:23:58 UTC]

Clang seems to be stricter than GCC as far as #includes go.
I have attached a patch that removes the libiberty.h include from util/cairo-trace/lookup-symbol.c. This makes the file compile. Both bfd.h and libiberty.h pull in ansidecl.h, which makes clang think there is a redefinition of the same objects. Compilation is now fine, I have yet to test run the program (cairo-trace) properly because I'm working remotely (needs a graphic environment to start applications for which to trace calls).
Note that cairo *still fails tests* with both clang-3.4.2 and GCC 4.8.3, which makes me think it's not a clang issue.

[Comment 9 Fabio Scaccabarozzi 2014-08-09 13:27:02 UTC]

Addendum: The program runs fine when invoked as "cairo-trace --help".
I couldn't find references of the problem being already fixed on the web, and I'm using binutils-2.24-r3.

[Comment 10 Pacho Ramos 2016-05-28 10:44:06 UTC]

What is the status of this with 1.14.6?

[Comment 11 Fabio Scaccabarozzi 2016-06-07 21:06:40 UTC]

I'm still hitting this with cairo-1.14.6 and clang/llvm-3.8.0.
Applying the patch I posted is still solving the issue for me.

[Comment 12 Chí-Thanh Christopher Nguyễn 2016-06-07 21:50:46 UTC]

The patch was not sent upstream from what I can tell, this would be the first step to get it applied.

[Comment 13 Fabio Scaccabarozzi 2016-06-09 21:37:30 UTC]

Bug opened:
https://bugs.freedesktop.org/show_bug.cgi?id=96467

[Comment 14 moxian 2017-07-13 03:19:44 UTC]

Even though the upstream bug is still open, I can currently compile x11-libs/cairo-1.14.8 and x11-libs/cairo-1.14.10 with clang-3.9.1 without applying any patches. Test suite passes (as long as I remove RESTRICT="test",  should not be there in the first place, since it's only set to prevent circular dependencies, but that's another story).

Should this bug be closed?

[Comment 15 Austin English (RETIRED) 2018-09-05 21:35:04 UTC]

(In reply to moxian from comment #14)
> Even though the upstream bug is still open, I can currently compile
> x11-libs/cairo-1.14.8 and x11-libs/cairo-1.14.10 with clang-3.9.1 without
> applying any patches. Test suite passes (as long as I remove
> RESTRICT="test",  should not be there in the first place, since it's only
> set to prevent circular dependencies, but that's another story).
> 
> Should this bug be closed?

I think so. It also works for me with cairo-1.14.12 and clang-6.0.1.