Anonymous | Login | Signup for a new account | 11-10-2008 11:34 PST |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||||
ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||||
0002064 | [uClibc] Other | minor | always | 02-07-08 19:30 | 03-20-08 23:59 | ||||
Reporter | michael_d | View Status | public | ||||||
Assigned To | uClibc | ||||||||
Priority | normal | Resolution | fixed | ||||||
Status | closed | Product Version | |||||||
Summary | 0002064: Library assumes presence of several syscalls | ||||||||
Description |
When compiled against unmodified Linux-2.0.40 headers, uClibc fails to compile because it assumes several 2.2+ syscalls are present. The syscalls in question are __NR_lchown, __NR_prctl, __NR_sendfile, __NR_setresuid, __NR_setresgid, __NR_sched_getaffinity, and __NR_sched_setaffinity. (I'm aware there's already a patch in buildroot for the last two.) It looks like there was an attempt to conditionally include setresuid() and setresgid(). But it doesn't work, as compilation fails with "'__EI_setresuid' aliased to undefined symbol '__GI_setresuid'". I've worked around the problem by modifying <asm/unistd.h> before building uClibc. For all syscalls except lchown(), letting them fail with ENOSYS produces results no more broken than glibc on the same kernel. lchown() wasn't a problem for me, as I've privately backported syscall 182 to my kernel. Note that problem 0001874 also needs to be fixed before compilation on Linux 2.0.40 can complete. |
||||||||
Additional Information | |||||||||
Attached Files | uClibc-0.9.29-condcalls.diff [^] (3,341 bytes) 03-13-08 05:09 | ||||||||
|
Copyright © 2000 - 2006 Mantis Group |