Bug 96467

Summary:	cairo-trace fails to compile with clang
Product:	cairo	Reporter:	Fabio Scaccabarozzi <fsvm88>
Component:	general	Assignee:	Chris Wilson <chris>
Status:	RESOLVED MOVED	QA Contact:	cairo-bugs mailing list <cairo-bugs>
Severity:	normal
Priority:	medium	CC:	austinenglish
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Fabio Scaccabarozzi 2016-06-09 21:36:22 UTC

The cairo-trace program included in the cairo release fails to build when using clang.
There is a lengthy and quite old bug in the gentoo bugzilla about this: https://bugs.gentoo.org/show_bug.cgi?id=483408

Can you please merge the following patch? https://483408.bugs.gentoo.org/attachment.cgi?id=382588

The patch removes the extra libiberty.h include, as both bfd.h and libiberty.h include ansidecl.h. I'm not sure why clang is so picky about this header and I'm not sure this is the proper way to fix the issue, but with the patch cairo builds fine, and the cairo-trace util seems to work properly (not segfaulting/crashing when invoked).

Additional details:
- The first version that failed for me was 1.12.16, current stable still fails
- When I tested with cairo 1.12.16, clang was version 3.3; current stable (3.8.0) still fails

Comment 1 Uli Schlachter 2016-06-10 14:11:41 UTC

I don't know what libiberty.h contains, but since it is included I guess that somewhere something might need something from that file. So doesn't this break compilation somewhere? Why not?

If the issue here really is "libiberty.h cannot be included after bfd.h was included", isn't that then a bug in one of these headers? Including headers should be idempotent (usually...).

Comment 2 Fabio Scaccabarozzi 2016-06-10 20:29:37 UTC

I don't know what libiberty.h contains either.
Please note that the two files are not supposed to be idempotent - bfd and libiberty are two distinct libraries. I've read the documentation and the wikis (https://en.wikipedia.org/wiki/Binary_File_Descriptor_library, https://en.wikipedia.org/wiki/Libiberty), apparently they are two libraries with two different goals in mind, which share a very important building block for implementation (ansidecl.h - "ANSI and traditional C compatibility macros").

It seems that lookup-symbol.c was first committed with both headers included in cairo, and that didn't change over releases. I have no clue why clang behaves this way when both are included and GCC happily ignores this, my guess is that clang is somehow more strict on checking includes and doesn't like duplicate definitions, even though they come from the very same header.

What I have tested is that without libiberty both compilers compile fine, but without bfd both will fail. That is due to bfd functions being used in lookup-symbol.c. Apparently no libiberty-specific symbols are included, otherwise both compilers would fail as well.

I don't think it's a bug in the headers, as they are written for two different things, even though they share a common include.

Comment 3 GitLab Migration User 2018-08-25 13:27:36 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/16.

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.