Hi, > >> Chris Clayton wrote: > >> > but make check hangs when > >> > gnulib-tests/test-lock is run. The log showed that the hang occurred > >> > somewhere after the > >> > message "Starting test_rwlock" was output > ... > > The only thing I can think of is that glibc is a bit old at 2.7, > > Using glibc-2.7 with a new kernel is unusual indeed.
But the kernel people try hard not to break backward compatibility, and while glibc-2.7 is not as bleeding edge as linux 2.6.34, it is less than 3 years old. You can easily reduce the size of test-lock.c so that only one of the four tests is run. The next step will be to manually expand the macros from gnulib's <lock.h>, so that you get 100% POSIX compliant source code. With that, you could go to the glibc people and ask for help. But given that glibc-2.7 is old, you would need someone else to reproduce it also with a newer glibc. And personally I would guess it's a breakage in the new linux 2.6.34. But in order to isolate a bug in the multithread system calls, you need help of a some super hacker like Ulrich Drepper or Ingo Molnar. So, can you trim down the testcase to something that fails with glibc-2.11 and submit that through the glibc bugzilla? Bruno
