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

Previous Next

Full log

Message #23 received at 6281 <at> debbugs.gnu.org (full text, mbox):

From: Chris Clayton <chris2553 <at> googlemail.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: bug-gnulib <at> gnu.org, 6281 <at> debbugs.gnu.org
Subject: Re: bug#6281: Fwd: Possible bug in coreutils-8.5 or associated gnulib
	version
Date: Fri, 28 May 2010 09:53:27 +0100

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.