On Thu, Dec 15, 2011 at 2:15 AM, peter green
peter.gr...@postgrad.manchester.ac.uk wrote:
While renaming the structure would be one soloution to the
conflicts changing a long standing* interface to solve a
problem that is arch specific and has only recently become a
significant issue** seems
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
On Thu, Dec 15, 2011 at 1:52 PM, peter green plugw...@p10link.net wrote:
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
Carlos O'Donell wrote:
As an upstream glibc maintainer I would be happy to see this fixed in
glibc and gdb, but nobody has stepped up to fix it.
Ok.
The `struct user` is used by the gdbserver code that uses ptrace
(PTRACE_PEEKUSR/POKEUSR) to peek/poke at the inferior and read out
stored
recently i've been seeing some packages FTBFS on armhf with definition
clashes of struct
user. Test building packages the package on armel has invariblly shown
the issue
happening there as well despite the same version of the source package
having built there
successfully in the past. I've also
5 matches
Mail list logo
