On Friday 28 May 2010, Jim Meyering wrote: > Chris Clayton wrote: > > Hi Jim, > > > > I've done some more testing and the outcome is reported below. > > ... > > [I've reformatted this paragraph for you -- wrapping to 100 columns > makes it render in a relatively hard-to-read manner on my 80-col window] > Sorry, I've reconfigured kmail to wrap at column 80.
> > If I add --enable-threads=pth to the call to configure, test-lock > > runs successfuly ever time. If I make it --enable-threads=posix (or > > let it default to posix), test-lock will very occasionally succeed, > > but more often than not hangs as per my report above. If I define > > ENABLE_DEBUGGING as 1 in test-lock.c, test-lock succeeds regardless of > > Thanks for the details. > > > the threading library that's used. I guess this all points to something > > like a thread sync problem in libpthread at glibc-2.7. However, it > > appears that the --enable-threads=blah setting only affects the test > > applications. Whatever I set it to, the coreutils binary rpm I produce > > only ever requires libpthread and only test-tls and test-lock switch > > between requiring libpthread and libpth depending on the setting. In > > that case I'm happy to build the package to use libpth. In any case, > > test-lock et al seem to me to be testing gnulib rather than coreutils, > > although happy to be corrected on that. > > That's right. The tests under coreutils' gnulib-tests/ directory > are unit tests of the gnulib modules used by coreutils. > However, as you would expect of thorough unit tests, in many cases they > test functionality that is seldom (or never) used in the parent package. > So if getting a working coreutils-8.5 package is all you want right now, > you're probably safe. Because my glibc is so old, I'm fine with that, but if the gnulib folks want to follow it up, I'm more than happy to help. -- The more I see, the more I know. The more I know, the less I understand. Changing Man - Paul Weller
