On Wed, May 12, 2010 at 08:02:53AM +0200, Steffen Sledz wrote: > 11.05.2010 16:27, Tom Rini wrote:
> -> 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. It does but... > Then you wrote that *every app* itself is responsible to handle syscalls > which are reported by autotools (linux-libc-headers) as *available* but ...what it does not do is emulate syscalls which are being used by applications directly. There are a bunch of kernel features which are used by glibc internally - for those it will just use fallbacks at runtime. For things like epoll which are used directly by applications it's up to the application to decide if it is willing or able to cope on older systems. For many kernel features there's no sane possibility of emulation. > are *not available* ? I can't believe that. This sounds absurd for me. glibc is frequently built for systems other than the one it runs on (obviously, OE is a big example here) so it needs to support building against a kernel other than the running one, and there's plenty of cases even with desktop/server systems where it's useful to be able to link against features which can't be run (eg, user installs old kernel for a binary driver, or a vendor wants to distribute a binary which can optionally use newer features but still run on older systems). _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
