Bug 428636 – net-misc/grive with >=sys-devel/binutils-2.22.90 - In file included from .../work/grive-0.2.0/libgrive/src/bfd/SymbolInfo.cc:25:0: /usr/include/bfd.h:37:2: error: #error config.h must be included before this header

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Steven Green 2012-07-30 10:56:16 UTC]

Created attachment 319708 [details]
Logfile from emerging grive

Compiling net-misc/grive-0.2.0 with binutil-2.22.90 generates a compiler error whilst including bfd.h:

In file included from /var/tmp/portage/net-misc/grive-0.2.0/work/grive-0.2.0/libgrive/src/bfd/SymbolInfo.cc:25:0:
/usr/include/bfd.h:37:2: error: #error config.h must be included before this header

This is similar to gentoo bug https://bugs.gentoo.org/show_bug.cgi?id=428506 

The binutil bugzilla bug 14243 at http://sourceware.org/bugzilla/show_bug.cgi?id=14243 indicates that anything using bfd.h must be build with autotools and include a config.h

[Comment 1 Steven Green 2012-07-30 11:45:55 UTC]

See grive issue: https://github.com/Grive/grive/issues/72

[Comment 2 Tassilo Horn 2012-09-14 21:42:44 UTC]

The hint to add a "#define PACKAGE" before the "#include <bfd.h>" in libgrive/src/bfd/SymbolInfo.cc made it compile again for me.

[Comment 3 Christoph Junghans (RETIRED) 2012-11-01 00:02:43 UTC]

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

[Comment 4 Christoph Junghans (RETIRED) 2012-11-01 03:08:13 UTC]

I added a workaround to the ebuild.

[Comment 5 Jeroen Roovers (RETIRED) 2012-11-01 03:30:57 UTC]

You are checking the wrong thing. binutils can be SLOTted so you should be checking the active ld version. Or better yet, don't check at all but provide a fix that fits all cases.

[Comment 6 Jeroen Roovers (RETIRED) 2012-11-01 03:39:34 UTC]

Also, flag-o-matic.eclass has append-cppflags for what you're doing.

[Comment 7 Christoph Junghans (RETIRED) 2012-11-01 04:21:14 UTC]

(In reply to comment #5)
> You are checking the wrong thing. binutils can be SLOTted so you should be
> checking the active ld version. Or better yet, don't check at all but
> provide a fix that fits all cases.
That is true, didn't think of multislot. I guess, always defining PACKAGE will not hurt.

(In reply to comment #6)
> Also, flag-o-matic.eclass has append-cppflags for what you're doing.
True, but for appending I prefer it this way and normally cmake ignores CPPFLAGS.

[Comment 8 Christoph Junghans (RETIRED) 2012-11-02 22:21:10 UTC]

(In reply to comment #7)
> (In reply to comment #5)
> > You are checking the wrong thing. binutils can be SLOTted so you should be
> > checking the active ld version. Or better yet, don't check at all but
> > provide a fix that fits all cases.
> That is true, didn't think of multislot. I guess, always defining PACKAGE
> will not hurt.
I had another look at the issue, it seems the PACKAGE check was added to make sure some HAVE_* were defined, so to be correct we will need to grep them from bfd.h and check for the corresponding function in libc.
At this point there is only one HAVE define, which appears in the following line
#if defined (__STDC__) || defined (ALMOST_STDC) || defined (HAVE_STRINGIZE)
Is it save to assume __STDC__ is defined?

I believe this is a bug in binutils, but spanKY seems to have a different opinion.

> (In reply to comment #6)
> > Also, flag-o-matic.eclass has append-cppflags for what you're doing.
> True, but for appending I prefer it this way and normally cmake ignores
> CPPFLAGS.
cmake-utils.eclass has support for CPPFLAGS hacked in, so it seems cleaner to add -DPACKAGE there.

[Comment 9 Christoph Junghans (RETIRED) 2012-11-13 02:36:19 UTC]

(In reply to comment #5)
> You are checking the wrong thing. binutils can be SLOTted so you should be
> checking the active ld version. Or better yet, don't check at all but
> provide a fix that fits all cases.
I improved cmake's check for the bfd library to check for broken bfd.h.