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
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...).
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.
-- 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.