On Tue, Apr 19, 2011 at 10:48 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 19 April 2011 20:37, Blue Swirl <blauwir...@gmail.com> wrote: >> On Tue, Apr 19, 2011 at 11:57 AM, Peter Maydell >> <peter.mayd...@linaro.org> wrote: >>> Work around a SPARC glibc bug which caused the epoll_create1 configure >>> test to wrongly claim that the function was present. Some versions of >>> SPARC glibc provided the function in the library but didn't declare >>> it in the include file; the result is that gcc warns about an implicit >>> declaration but a link succeeds. So we build the configure test with >>> -Werror to avoid the test passing but then a -Werror qemu build >>> failing. >> >> But then epoll would not be used. > > I think that's fine -- on a system which isn't advertising epoll > in its include files we shouldn't be trying to use it. It might > be buggy, or not the same function at all, for instance. > > Anybody who actually cares about epoll can upgrade their libc :-)
Maybe epoll is not so interesting as madvise. But the check is not very specific, there could be some unrelated warning with the headers. How about checking in the compiled file for for example EPOLLIN, that should give a clear build failure if the header is missing?
