Summary: | sys-kernel/ksymoops-2.4.11-r1 - In file included from ksymoops.h:9:0, from ksymoops.c:14: /usr/include/bfd.h:37:2: error: #error config.h must be included before this header | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Gary E. Miller <gem> |
Component: | [OLD] Core system | Assignee: | Gentoo Kernel Miscellaneous <kernel-misc> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | bug, ian, jason.mours, maggu2810, Martin.vGagern, mmokrejs, treecleaner, wbrana |
Priority: | Normal | Keywords: | PMASKED |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | Pending Removal: 2013-08-21 | ||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log
Workaround patch build.log - JM |
Description
Gary E. Miller
2012-07-31 00:26:09 UTC
Created attachment 319800 [details]
build.log
Similar to bugs 428636 and 428506 See the binutils bugtracker at http://sourceware.org/bugzill/show_bug.cgi?id=14243 Created attachment 321748 [details, diff]
Workaround patch
Add a dummy macro called `PACKAGE` to ksymoops.h before the `#include <bfd.h>`. This is enough to stop <bfd.h> from binutils 2.22.90 complaining.
*** Bug 431002 has been marked as a duplicate of this bug. *** (In reply to comment #4) > Add a dummy macro called `PACKAGE` to ksymoops.h before the `#include > <bfd.h>`. This is enough to stop <bfd.h> from binutils 2.22.90 complaining. http://sourceware.org/bugzilla/show_bug.cgi?id=14243#c1 indicates that this solution might be have unintended consequences. Quoting from that comment: "This is a correctness issue. bfd.h and the headers that bfd.h #include test at least one HAVE_* macro. So you need to include the file that defines those HAVE_* macros before bfd.h. You may argue that the use of HAVE_STRINGSIZE will never affect any host that builds oprofile. While that may be true, it's still a correctness issue. Future versions of bfd.h may test other HAVE_* macros." Looking at the headers, this should probably be "HAVE_STRINGIZE" not "HAVE_STRINGSIZE". And as long as __STDC__ is defined, the value of HAVE_STRINGIZE should be irrelevant. But the fact about possibly different behaviour in a future release of binutils remains. Even now, there are other HAVE_* macros in use in binutils headers, though only in libiberty.h which apparently isn't included by bfd.h. In short, the workaround seems to work for now, but might break again in the future. I'd like to at least document this possibility here, with this comment. Created attachment 340896 [details] build.log - JM I was able to pull a few a bit more out ... not sure if these affected object files will help. x86_64-pc-linux-gnu-gcc -march=native -Os -pipe -ggdb -Dlinux -Wall -Wno-conversion -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -DINSTALL_PREFIX="\"/usr\"" -DCROSS="\"\"" -DDEF_KSYMS=\"/proc/ksyms\" -DDEF_LSMOD=\"/proc/modules\" -DDEF_OBJECTS=\"/lib/modules/*r/\" -DDEF_MAP=\"/usr/src/linux/System.map\" -c -o symbol.o symbol.c In file included from ksymoops.h:9:0, from io.c:11: /usr/include/bfd.h:37:2: error: #error config.h must be included before this header In file included from ksymoops.h:9:0, from map.c:11: /usr/include/bfd.h:37:2: error: #error config.h must be included before this header In file included from ksymoops.h:9:0, from ksymoops.c:14: /usr/include/bfd.h:37:2: error: #error config.h must be included before this header In file included from ksymoops.h:9:0, from misc.c:11: /usr/include/bfd.h:37:2: error: #error config.h must be included before this header In file included from ksymoops.h:9:0, from object.c:11: /usr/include/bfd.h:37:2: error: #error config.h must be included before this header In file included from ksymoops.h:9:0, from ksyms.c:11: /usr/include/bfd.h:37:2: error: #error config.h must be included before this header In file included from ksymoops.h:9:0, from re.c:11: /usr/include/bfd.h:37:2: error: #error config.h must be included before this headerIn file included from ksymoops.h:9:0, from symbol.c:11: /usr/include/bfd.h:37:2: error: #error config.h must be included before this header make: *** [io.o] Error 1 make: *** Waiting for unfinished jobs.... In file included from ksymoops.h:9:0, from oops.c:11: /usr/include/bfd.h:37:2: error: #error config.h must be included before this header ksymoops.c: In function 'parse': ksymoops.c:452:6: warning: pointer targets in passing argument 2 of 'adhoc_addresses' differ in signedness [-Wpointer-sign] ksymoops.c:264:13: note: expected 'const unsigned char *' but argument is of type 'char *' make: *** [ksyms.o] Error 1 make: *** [map.o] Error 1 make: *** [ksymoops.o] Error 1 make: *** [object.o] Error 1 make: *** [misc.o] Error 1 oops.c: In function 'Oops_code_values':re.c: In function 're_compile': re.c:34:5: warning: format '%d' expects argument of type 'int', but argument 2 has type 'size_t' [-Wformat] oops.c:363:7: warning: pointer targets in assignment differ in signedness [-Wpointer-sign] oops.c: In function 'Oops_decode': oops.c:2248:5: warning: pointer targets in passing argument 2 of 'Oops_code_values' differ in signedness [-Wpointer-sign] oops.c:339:12: note: expected 'unsigned char *' but argument is of type 'char *' oops.c: In function 'Oops_read': oops.c:2464:5: warning: pointer targets in passing argument 1 of 'Oops_decode' differ in signedness [-Wpointer-sign] oops.c:2238:13: note: expected 'const unsigned char *' but argument is of type 'const char *' make: *** [re.o] Error 1 make: *** [symbol.o] Error 1 make: *** [oops.o] Error 1 emake failed ref bug 430706 dev-util/mutrace-0.2 with similar bfd.h issues. Reading the correctness issues on sourceware, I'm not sure if it's fixable. !PING! ... was wondering as to the status of this issue. I'm sharing Gary's concerns over future errata or outright breakage with the */dummy/* package being a workaround. janice, my gentoo, is a traced stage3 -march=native !(-Os)! -pipe(ed) -ggdb that is over a year old this summer. I am very deep into the machine at this point. Anything that 'may' pop up 6-8 months from now, especially with the 3.9 tracing bug getting squished well into 3.10, is just reason to pop some pepcid and hum along to the tums commercials. That being said, I can only express how much further I can dive into the silicon with the addition of ksymoops. Especially before I mlton her... then move into gcc-4.8 territory. BUT I will not venture outside of ~testing for package assimilation/integration. If it's a no go with bfd.h & binutils so be it. I'll live without. A suggested fix by Mike Frysinger is ``people can #define PACKAGE "foo" just as easily as autotools'' (see <http://sourceware.org/bugzilla/show_bug.cgi?id=14243#c10>), which is basically what my workaround patch did. It may also be worth pointing out that ksymoops is not useful for analyzing the Oops messages produced by 2.6 and 3.x kernels, only for 2.4 kernels. (In reply to Ian Abbott from comment #9) > It may also be worth pointing out that ksymoops is not useful for analyzing > the Oops messages produced by 2.6 and 3.x kernels, only for 2.4 kernels. OK, CCing treecleaners for removal then (In reply to Ian Abbott from comment #9) > A suggested fix by Mike Frysinger is ``people can #define PACKAGE "foo" just > as easily as autotools'' (see > <http://sourceware.org/bugzilla/show_bug.cgi?id=14243#c10>), which is > basically what my workaround patch did. > > It may also be worth pointing out that ksymoops is not useful for analyzing > the Oops messages produced by 2.6 and 3.x kernels, only for 2.4 kernels. That may be true for human readable output, I'm pretty sure that it still produces interpretive machine output for the 2.6 & 3.x kernels. Well Documentation/oops-tracing.txt in the kernel sources says this right at the top of the file: NOTE: ksymoops is useless on 2.6. Please use the Oops in its original format (from dmesg, etc). Ignore any references in this or other docs to "decoding the Oops" or "running it through ksymoops". If you post an Oops from 2.6 that has been run through ksymoops, people will just tell you to repost it. (In reply to Ian Abbott from comment #12) > Well Documentation/oops-tracing.txt in the kernel sources says this right at > the top of the file: > > NOTE: ksymoops is useless on 2.6. Please use the Oops in its original format > (from dmesg, etc). Ignore any references in this or other docs to "decoding > the Oops" or "running it through ksymoops". If you post an Oops from 2.6 > that > has been run through ksymoops, people will just tell you to repost it. Fair enough ... I can't ignore the manual, but from a GDB standpoint, when compiling global heuristics... the output is useful for pulling out errata. /usr/include/bfd.h:37:2: error: #error config.h must be included before this header i had some problem today, resolved using workaround patch (In reply to Alice Ferrazzi from comment #14) > /usr/include/bfd.h:37:2: error: #error config.h must be included before this > header > > i had some problem today, resolved using workaround patch I know the patch resolves the build issues. Here is what I know of ksymoops, it is outdated as generates useless human interpretive output. But as it was explained to me, the source code is *amazing* at analyzing the kernel - 2.4, 2.6 , 3.x , etc. THUS, as you introduce it to your @world and *assimilate* it into your system - glibc, gcc, binutils, sed, etc. acquire these functions from ksymoops source and through the magic of GNU/Linux & *emerging* an evolving build environment over time a superior kernel can be produced. Which is why I stress -march=native & -Os. The patch defeats the purpose and the outdated human readable output give no reason to have it in your system to begin with. my 2cents... dropped |