Re: "struct user" conflicts on armel and armfh
>As a first step why don't you try breaking the header include chain in
glibc, and rebuild gdb to ensure everything works?
It looks like there are two places the chain could reasonablly be
broken. sys/ucontext.h could stop including sys/procfs.h
(this would match amd64) or signal.h could stop including sys/ucontext.h
(this would match armel squeeze)
I first tried breaking the chain by removing the include of sys/procfs.h
from sys/ucontext.h (this would make arm* consistent with i386 and
amd64) but it seems sys/ucontext.h on arm DOES use a couple of things
from sys/procfs.h so breaking the chain at this point would require
investigating those.
Next I tried breaking the chain by commenting out the include of
sys/ucontext.h in signal.h. This seemed more positive, a test program
that included signal.h still built fine as did gdb.
So that brings us back to why is signal/h including sys/ucontext.h by
default in wheezy/sid when it didn't do so in squeeze. It seems the
cause is the change of the following ifdef
Squeeze:
#ifdef
__USE_XOPEN
/* This will define `ucontext_t' and `mcontext_t'.
*/
# include
<sys/ucontext.h>
# endif
Wheezy/Sid:
# if defined __USE_XOPEN || defined
__USE_XOPEN2K8
/* This will define `ucontext_t' and `mcontext_t'.
*/
# include
<sys/ucontext.h>
# endif
seems to be defined by default
From my tests it seems that in both squeeze and sid __USE_XOPEN2K8 gets
defined by default
(in ) but __USE_XOPEN does not.
so this change to the ifdef changed it from "default no" to "default yes"
Reverting the change the ifdef would solve the issue but before
submitting a patch to actually
do that I would like to know why the change was made in the first place.
Reply to: