11.05.2010 16:27, Tom Rini wrote: > All of this information is _not_ coming from glibc claiming that a > syscall exists, but it's coming from the linux-libc-headers having them > (which is why if you downgrade, they build and run as you expect them > to). Then there's the problem, as others have stated, that it's up to > userland to gracefully handle if a syscall isn't really available.
<grrrr> Now i'm totally confused. Here's a short summary as i understand this thread (may be i misunderstand something). My initial understanding was: linux-libc-headers match to kernel version -> autotools report existing syscalls -> apps can use them -> fine Then Koen wrote: no chance to change linux-libc-headers for angstrom Graeme and Phil wrote something like no problem, "glibc was supposed to gracefully fall back on missing syscalls". What i understand as linux-libc-headers may be newer than kernel version -> autotools report availability of some syscalls (e.g. inotify_init1 or epoll_create1) -> apps can use them -> if called on older kernels glibc will handle this "gracefully" -> fine But tests showed that glibc did not handle syscalls this way. Then you wrote that *every app* itself is responsible to handle syscalls which are reported by autotools (linux-libc-headers) as *available* but are *not available* ? I can't believe that. This sounds absurd for me. So please enlighten my confusions. Regards, Steffen PS: > You noted before that glib-2.0 falls back to using something very > inefficient, rather than a less efficient syscall that does exist, yes? What glib does is checking the availability (by using autotools) of inotify (in various levels), fam, or plain polling. _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
