[lfs-dev] gettext test stall, was Re: glibc-2.25 compile error
bruce.dubbs at gmail.com
Fri Feb 24 20:17:28 PST 2017
Ken Moffat wrote:
> On Fri, Feb 24, 2017 at 05:14:16AM +0000, Ken Moffat wrote:
>> On Thu, Feb 23, 2017 at 05:28:39PM +0000, Ken Moffat wrote:
>>> 1. I've built current svn (sysv) with 4.9.11 headers on two
>>> machines. One was running 4.10-rc7 for the build, and that was all
>>> fine. The other was running 4.10.0, and there the gettext tests
>>> stalled at the start using all cores and I ended up not running
>>> those tests.
> Not sure if this will get into 8.0, but I've now completed the build
> on the machine which shows the problem. So, on the assumption it
> doesn't, I'm following up here. Three things are worth noting:
> 1. coreutils and findutils are also affected.
> 2. when I built LFS in January on that machine, the same versions of
> these packages ran through their testsuites without any problem, so
> I guess other people may experience this.
> 3.when I tested a few hours ago on the previously completed 8.0
> system, only one of the two test-lock tests in gettext needed to be
> suppressed. But in chroot I had to suppress both of them.
> And beyond what I wrote last night, both coreutils and findutils
> also run test-lock from gnulib, and both are equally affected.
> I'm using the following seds to remove only test-lock :
> sed -i '/^TESTS =/d' gettext-runtime/tests/Makefile.in
> sed -i 's/test-lock..EXEEXT.//'
> sed -i '/test.lock/s/^/#/' gnulib-tests/gnulib.mk
> (thanks to Bruce for that one)
> sed -i 's/test-lock..EXEEXT.//' tests/Makefile.in
> I'm not proud of the '..EXEEXT.' seds - they trash the related log
> dependency, but fortunately it never gets used. Similarly the
> gettext-runtime sed looks dramatic, but it jsut turns 1 test into 0
> I created ticket #4055 to try to make this manageable (i.e. at some
> point these packages will have updated gnulib and the seds will not
> be needed - but how will we know?) but the details there might be
> inadequate re the second test in gettext.
Ken, please go ahead and make the changes. You are the one most familiar
with the explanations.
More information about the lfs-dev