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 <[EMAIL PROTECTED]> ----- Subject: Bug#116804: libc6-dev: bits/sigcontext.h #include's asm/types.h (indirectly) on ia64 From: James Troup <[EMAIL PROTECTED]> 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 \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=========------=======-------------=-=-----=-===-======-------=--=---'
