Bug#223891: kdeutils_4:3.1.4-1(mips/unstable): FTBFS: SYS_* seems to be missing from bits/syscall.h ?
> From what I've been told this is normal. Apparently using syscalls isn't
> supposed to be done from userspace, even though the SYS_* syscalls are
> there only for compat reasons to begin with... Considering the older
> headers had it though I think the people telling me its supposed to be
> missing are on crack. ;)
>
> In any case I know how to fix the issue for kdeutils, just change
> syscall(SYS_sysinfo,foo) to sysinfo(foo).
Exactly. From looking through "dmapi" and "kdeutils", their syscall()
usage is not good:
kdeutils:
ksim/systeminfo.cpp: if (syscall(SYS_sysinfo, &system) < 0) {
dmapi:
libdm/dm_handle2path.c: cnt = syscall(SYS_getdents, dirfd,
Both are provided as sysinfo(2) and getdents(2). Moreover, glibc uses
getdents64() if 64bit getdents() is available (and in kernel 2.4, it's
default behavior), so it's good idea to prevent from using raw syscall
interface.
However, bits/syscall.h should be provided by glibc - it should be
generated from arch/mips/unistd.h. In kernel 2.6 mips guys introduces
o32 changes for syscall, and we now have linux-kernel-headers which is
derived from 2.6, so it seems glibc does not handle this well. Thus,
mips custom syscall-list.h code in Makefile mis-grep __NR_O32_Linux
and mis-generate syscall.h. I think it's not hard fix, but
unfortunatelly we have no glibc build and test machine for mips
because we're warned from casals.debian.org that should be avoided to
use handcraft work. I give up to track this currently.
Debian mips guys, if you have the latest sid and glibc build
environment, please track this. If you don't know about this issue
well, I can tell you where the problem exists.
From above analysis, I think this bug should be devided into 3 parts:
for glibc (mips bits/syscall.h lack: important bug), for kdeutils and
dmapi (use standard interface: grave bug). If no one objects, I'll do
so.
Regards,
-- gotom
Reply to: