bug#6281: Fwd: Possible bug in coreutils-8.5 or associated gnulib version

[Jim Meyering]

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]
> 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.