"struct user" conflicts on armel and armfh
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
/* This is somewhat modelled after the file of the same name on SVR4
systems. It provides a definition of the core file format for ELF
used on Linux. It doesn't have anything to do with the /proc file
system, even though Linux has one.
Anyway, the whole purpose of this file is for GDB and GDB only.
Don't read too much into it. Don't use it for anything other than
GDB unless you know what you are doing. */
and sys/user.h has the following comment
/* The whole purpose of this file is for GDB and GDB only. Don't read
too much into it. Don't use it for anything other than GDB unless
you know what you are doing. */
meanwhile sys/wait.h has the following comment
/*
*<---->POSIX Standard: 3.2.1 Wait for Process Termination<----><sys/wait.h>
*/
,signal.h has the following comment
/*
*<---->ISO C99 Standard: 7.14 Signal handling <signal.h>
*/
and sys/ucontext.h has the following comment
/* System V/ARM ABI compliant context switching support. */
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?
Reply to: