Summary: | gdb-5.3 failed to compile on sparc64 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jack Morgan (RETIRED) <jmorgan> |
Component: | [OLD] Development | Assignee: | Sparc Porters <sparc> |
Status: | VERIFIED FIXED | ||
Severity: | normal | CC: | kumba |
Priority: | High | ||
Version: | 1.4_rc1 | ||
Hardware: | Sparc | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Patch /usr/include/sus/ucontext.h -> local copy of "ucontext.h" |
Description
Jack Morgan (RETIRED)
2002-12-28 20:10:25 UTC
Yes. Here is why it fails for me: gdb/sparc-nat.c has both #include <signal.h> #include <asm/reg.h> signal.h includes <ucontext.h> You can't have both <ucontext.h> & <asm-sparc/reg.h> because: This eventually gets you two conflicting definitions for the structures (fpq, fpu, fq): One set from <sys/ucontext.h>, and one from <asm-sparc/reg.h> You can make the compile go through if you make a local copy of <ucontext.h> which includes <asm/reg.h> (and then fix up the definitions in ucontext.h which reference the fpu structure). The resulting gdb program seems to work, but I am far from a gdb expert, and so I can't tell if it does anything correctly beyond basic functioning. And, for what it's worth, this comes about because of the "-D_XOPEN_SOURCE=500", which causes <features.h> (included by <signal.h>) to #define __USE_XOPEN 1 #define __USE_X_OPEN_EXTENDED 1 which in turn gets <signal.h> to do #include <ucontext.h> But in fact, as previously mentioned, you can't have #include <ucontext.h> #include <asm-sparc/reg.h> which is what you get. can you include your local copy of ucontext.h so we can add this into the ebuild? Created attachment 7368 [details, diff]
Patch /usr/include/sus/ucontext.h -> local copy of "ucontext.h"
Yes, I can . I hadn't noticed the comment, or I'd have responded sooner. I think the patch is attached as patch#7368. If not, please contact me directly at "fmccor@inforead.com" for anything you need. It will patch </usr/include/sys/ucontext.h> into a local copy which can live in the gdb-5.3/gdb directory. This is useful only for gdb, of course, because it does not define anything defined in <usr/include/ucontext.h>, but it seems to be good enough for <signal.h> in the gdb context. I hesitate to recommend it for general consumption; it's just something I threw together to get around the compilation problem. I have checked again that it does fix the reported problem, though (at least so far as the conflicting declarations go.) Very quick check: --- define _XOPEN_SOURCE 500 #include <signal.h> #include <asm/reg.h> --- should fail without patch, succeed with. There is a problem here that needs to be fixed in <usr/include/sys/ucontext.h> but I don't know enough about what it has to define to suggest this as a general patch. Sorry for the delay in answering. gdb-5.3 is now -sparc, 5.2.1 builds/runs fine on sparc, and should fulfill any gdb dependancies Well, not quite. 1. Maybe it's just me, but I found versions of gdb to be unusable for getting a quick snapshot of X-programs because of very long startup times after the 'creating new thread' message, and this is not the case with gdb-5.3, last I checked. 2. There's still a problem with the /usr/include files, because of the conflicting definitions demonstrated by the three line example in comment 5. On the other hand, once you get it built, gdb-5.3 seems to run OK on sparc... Closing |