[james@nocrew.org: Bug#116804: libc6-dev: bits/sigcontext.h #include's asm/types.h (indirectly) on ia64]
Anyone mind commenting on this? IMO, asm/fpu.h should wrap anything that
sigcontext.h doesn't need with "#ifdef __KERNEL__".
----- Forwarded message from James Troup <james@nocrew.org> -----
Subject: Bug#116804: libc6-dev: bits/sigcontext.h #include's asm/types.h (indirectly) on ia64
From: James Troup <james@nocrew.org>
Package: libc6.1-dev
Version: 2.2.4-3
Severity: important
On ia64 <bits/sigcontext.h> #includes <asm/fpu.h> which #includes
<asm/types.h>. This is bad because <asm/types.h> isn't designed to be
#included by unwitting applications[1] and I don't think #includ-ing
<signal.h> counts you in as being a witting(?) accomplice. I'm not
sure if this is glibc's, the kernel's or dancer-ircd's fault (though,
I doubt the latter[2]); but I'm sure you'll reassign as appropriate
;-)
| Automatic build of dancer-ircd_1.0.17-1 on caballero by sbuild/ia64 1.159
| Build started at 20011023-1511
| ******************************************************************************
[...]
| ** Using build dependencies supplied by package:
| Build-Depends: debhelper (>> 3.0.0), docbook-utils, zlib1g-dev, jade, html2text
[...]
| gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -O2 -Wall -Wno-unused -c `test -f ircd.c || echo './'`ircd.c
| In file included from /usr/include/asm/fpu.h:9,
| from /usr/include/bits/sigcontext.h:27,
| from /usr/include/signal.h:307,
| from ircd.c:73:
| /usr/include/asm/types.h:25: conflicting types for `umode_t'
| ../include/client.h:108: previous declaration of `umode_t'
| make[2]: *** [ircd.o] Error 1
| make[2]: Leaving directory `/build/buildd/dancer-ircd-1.0.17/src'
A complete build log can be found at
http://buildd.debian.org/build.php?arch=ia64&pkg=dancer-ircd&ver=1.0.17-1
--
James
[1] * This file is never included by application software unless
* explicitly requested (e.g., via linux/types.h) in which case the
* application is Linux specific so (user-) name space pollution is
* not a major issue. However, for interoperability, libraries still
* need to be careful to avoid a name clashes.
[2] I don't think assuming one can define your own
type/struct/variable whatever call'umode_t' is unreasonable
(especially if you're only including POSIX things like <signal.h>)
and it works on most (all?) of our other architectures
----- End forwarded message -----
--
.----------=======-=-======-=========-----------=====------------=-=-----.
/ Ben Collins -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Reply to: