[Top][All Lists]

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

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]