bug#6281: Fwd: Possible bug in coreutils-8.5 or associated gnulib versio (original) (raw)

[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

From: Chris Clayton
Subject: bug#6281: Fwd: Possible bug in coreutils-8.5 or associated gnulib version
Date: Fri, 28 May 2010 09:53:27 +0100
User-agent: KMail/1.9.10

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 > ENABLEDEBUGGING 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