[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