----- Original Message ----- From: "Bruce Dubbs" <[email protected]> To: "LFS Developers Mailinglist" <[email protected]> Sent: Sunday, February 06, 2011 7:28 PM Subject: Re: LFS SVN-20110204 error report
... > >>>> glibc: > >>> Did you have a random result at during glibc .configure with this test > >>> checking whether ranlib is necessary... > >> I have 'no' and haven't noticed it before. Perhaps it is dependent on > >> the host system. > > > > After some hard time trying to reproduce, I finally write the attached > > script inspired by configure. > > It find ranlib is not needed most of the time but sometime find yes and in > > my script that will break the loop. > > > > Random answer could be found on any machines, and there is more luck to fail > > on a loaded one. > > > > I have not enought knowledge of strace to understand what happen. > > My understanding is that the test fail when 'ranlib conftest.a' is not run > > on the same second than previously created archive. > > ranlib "generates an index to the contents of an archive and stores it > in the archive". It would appear that the problem you are running into > is a race condition of some kind. What were your results of the script? > That is, how often did it pass/fail? > > -- Bruce The script I send run until test fail. This vary from 1 to 150 attempts. But it /always/ display 1 s between archive creation and first 'yes'. I would say /always/ that my bash script has no atomic behavior, and second may change between archive creation and START variable update. In that case, TIMETOFAIL could be 0. Test failure is just really a race that got lost because ranlib run on the second after the archive was created (to my understanding). Like my script, create an archive, copy that archive to keep the original, add a sleep 1 s, and everytime ranlib run against the archive, you would have a different archive when checking against the original. On unloaded machine, just running glibc configure script in a loop, the 'yes' rate is in the order of less than 1%. I had between 5 to 8 yes on 2000 attempts depending of the machines. But that really depend on the machine load, how many -j to make (I usually have make -j 1 or log are hard to read and to much random to diff them). When compiling entire LFS, there is more load during a long period and glibc is build after binutils/gcc. I would not have noticed if the 'yes' failure was so low in real usage. Gilles -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
