@petergreen: "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 seen mention of this issue in bug 
reports from others.
Afaict so far this issue has been dealt with on the appliation side but 
i'm not convinced
that expecting application developers to rename a structure that uses a 
common and
obvious name is reasonbable.
taking ratbox-services as an example the current version was built 
successfully on
armel 563 days ago, it failed on armhf 3 days ago.
-DHELPDIR=\"/usr/share/ratbox-services/help\" -DLANGDIR=\"/usr/share/ratbox-services/langs\" -c c_error.c
In file included from c_error.c:38:0:
../include/client.h:42:8: error: redefinition of 'struct user'
/usr/include/arm-linux-gnueabihf/sys/user.h:49:8: note: originally defined here
make[2]: *** [c_error.o] Error 1
I have reproduced this issue on armel sid and armel wheezy. The package
builds succesfully on armel squeeze.
Some testing reveals that in this case sys/user.h is pulled in by sys/procfs.h which in turn 
is pulled in by sys/ucontext.h which is pulled in by signal.h which is in turn pulled in by
signal.h which is in turn pulled in by sys/wait.h which is pulled in by a header in the app.
On amd64 (and presumablly other architectures) sys/ucontext.h does not include sys/procfs.h
so the issue does not happen.
I then took a look at the comments in the various headers along the chain.
sys/procfs.h has the following comment
<quote>
and sys/user.h has the following comment
meanwhile sys/wait.h has the following comment
,signal.h has the following comment
and sys/ucontext.h has the following comment
So now i've described the situation I have two questions
why the heck are headers that are supposedly for "GDB and GDB" only
and that define a structure name that is likely to conflict with 
structures in an application being pulled in by headers that are
supposed to be implementing standard interfaces?
Do porters and/or glibc maintainers think this should be dealt
with on the libc6-dev side or should I continue to file patches 
that deal with this issue on the application side?
To UNSUBSCRIBE, email to <email_address>
with a subject of "unsubscribe". Trouble? Contact <email_address>
Archive: <url>"
    @carlos: "On Tue, Dec 13, 2011 at 6:59 PM, peter green
<quote>
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.
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 register values from the USER area. The userspace definition of
`struct user` is equivalent to task_regs(child) layout and is an
agreement between the kernel and userspace for debugging.
There appears to be no good reason for it to be called `struct user`
on Linux (on other OSs this is harder to control), it should have been
named something that doesn't clash with the applications namespace
e.g. struct __user.
Are you volunteering to change glibc and gdb, and work with upstream
to get the changes merged?
Cheers,
Carlos.
To UNSUBSCRIBE, email to <email_address>
with a subject of "unsubscribe". Trouble? Contact <email_address>
Archive: <url>"
    @petergreen: "<quote>
Ok.....
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 like a wrong approach to me.
The real problem IMO is that headers that are supposed to be
implementing special purpose interfaces for debugging are
being pulled in by headers that are supposed to be implementing
common public interfaces.
* at least as far back as debian slink
** In squeeze armel signal.h would only include sys/ucontext.h
  if explicit defines were set. In wheezy and sid it seems to
  include it by default.
Depends on what exactly is involved in doing that and whether we
can agree on how things should be fixed.
As I said i'm not convinced that gdb needs to be changed.
To UNSUBSCRIBE, email to <email_address>
with a subject of "unsubscribe". Trouble? Contact <email_address>
Archive: <url>"
    @carlos: "On Thu, Dec 15, 2011 at 2:15 AM, peter green
<quote>
As a first step why don't you try breaking the header include chain in
glibc, and rebuild gdb to ensure everything works?
Applications that actually need `struct user' will need to pull it in
explicitly instead of implicitly through another header.
One thing I wanted to check, but can't (the site is still undergoing
reconstruction after the security breach), is whether or not LSB
documents this interface as pat of the standard.
If it was documented in LSB (which has an ISO standard), you could
argue that the application is non-conforming to LSB, and that the real
fix is to stop using `struct user' because it's part of the standard.
Cheers,
Carlos.
To UNSUBSCRIBE, email to <email_address>
with a subject of "unsubscribe". Trouble? Contact <email_address>
Archive: <url>"
    @plugwash: " >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.
To UNSUBSCRIBE, email to <email_address>
with a subject of "unsubscribe". Trouble? Contact <email_address>
Archive: <url>"
    @carlos: "<quote>
Look at the git logs for upstream glibc, find the author and ask them?
Cheers,
Carlos.
To UNSUBSCRIBE, email to <email_address>
with a subject of "unsubscribe". Trouble? Contact <email_address>
Archive: <url>"
{'source': 'USENET', 'other_information': '{"reply_count": 5, "forum_name": "linux.debian.maint.glibc.20140825.mbox"}', 'file': 'data/output/usenet-linux.debian.parquet'}