Am 10.05.2010 21:14, Tom Rini wrote: > Looking at it again and based on what Khem said (and re-reading your > failures), the problem is not with glibc, but with other programs (glib, > udev are both mentioned specifically) and these programs specifically > not failing gracefully. For example, it's quoted over in: > http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-May/019626.html > that glib falls way back. I think Phil was wrong here and without > checking the code, I imagine glib is trying fancy newer syscall, > failing, and then falling far back, rather than to just inotify_init as > you expected. So the bug here is with glib. > > As for the udev issue, I do not know how they will react to making the > udev version be soft-assign as that too may raise issues. And iirc, > udev is or at least can be more tied to min kernel versions.
No, it seems not to be a problem of glib, rsyslog, or udev. As i see in the build logs glibc is build using --enable-kernel=2.6.16 (i do not know any --with-kernel option). After running autotools config.h of e.g. glib-2.0 contains /* Define to 1 if you have the `inotify_init1' function. */ #define HAVE_INOTIFY_INIT1 1 So the glib-2.0 is allowed to use inotify_init1. But this is only available for kernel version >= 2.6.27. Same behaviour for epoll_create1 in e.g. rsyslog /* Define to 1 if you have the `epoll_create' function. */ #define HAVE_EPOLL_CREATE 1 /* Define to 1 if you have the `epoll_create1' function. */ #define HAVE_EPOLL_CREATE1 1 Conclusion: glibc reports functions "available" which are not available for our kernel 2.6.24 (and not "emulated" inside glibc). :( Regards, Steffen _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
