|
From: Julian S. <js...@ac...> - 2009-07-15 15:32:48
|
Hi, A couple of times recently I've seen the following build failure: Making install in VEX mv: cannot stat `.deps/libvex_amd64_linux_a-guest_x86_toIR.Tpo': No such file or directory make[3]: *** [libvex_amd64_linux_a-guest_x86_toIR.o] Error 1 make[2]: *** [install] Error 2 make[1]: *** [install-recursive] Error 1 make: *** [install] Error 2 make: *** Waiting for unfinished jobs.... Making all in coregrind although it still seems to go on and complete the build OK, which is a bit odd. I don't remember this from before. It doesn't happen from a clean checkout build, only a rebuild, and only when I rebuild using my standard "rebuild-from-scratch" script shown below. Perhaps related to the -j 2 ? Anyone else seen this? J #!/bin/sh make --quiet -k distclean rm -rf Inst ./autogen.sh ./configure --prefix=`pwd`/Inst make -j 2 --quiet all install |
|
From: Tom H. <to...@co...> - 2009-07-15 15:39:35
|
On 15/07/09 16:40, Julian Seward wrote: > A couple of times recently I've seen the following build failure: > > Making install in VEX > mv: cannot stat `.deps/libvex_amd64_linux_a-guest_x86_toIR.Tpo': No such file > or directory > make[3]: *** [libvex_amd64_linux_a-guest_x86_toIR.o] Error 1 > make[2]: *** [install] Error 2 > make[1]: *** [install-recursive] Error 1 > make: *** [install] Error 2 > make: *** Waiting for unfinished jobs.... > Making all in coregrind > > although it still seems to go on and complete the build OK, which is > a bit odd. I don't remember this from before. > > It doesn't happen from a clean checkout build, only a rebuild, and > only when I rebuild using my standard "rebuild-from-scratch" script > shown below. Perhaps related to the -j 2 ? Inconsistent failures when using parallel make are usually a sign that there is a dependency missing so that it is trying to run a step before all it's dependencies are satisfied. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Nicholas N. <n.n...@gm...> - 2009-07-15 22:22:50
|
On Thu, Jul 16, 2009 at 1:39 AM, Tom Hughes<to...@co...> wrote: > On 15/07/09 16:40, Julian Seward wrote: > > Inconsistent failures when using parallel make are usually a sign that > there is a dependency missing so that it is trying to run a step before > all it's dependencies are satisfied. When I remove the .NOTPARALLEL directives I tested it a bit but I can certainly believe there are missing dependencies. Maybe I should start using -j myself... Nick |
|
From: Julian S. <js...@ac...> - 2009-07-15 23:22:03
|
On Thursday 16 July 2009, Nicholas Nethercote wrote: > On Thu, Jul 16, 2009 at 1:39 AM, Tom Hughes<to...@co...> wrote: > > On 15/07/09 16:40, Julian Seward wrote: > > > > Inconsistent failures when using parallel make are usually a sign that > > there is a dependency missing so that it is trying to run a step before > > all it's dependencies are satisfied. Yes. That's what I was/am afeard of. Whatever it is, it's pretty elusive, though. A couple of spins of "make clean ; make -j 16" produces no problems. This is on a Core 2 Duo. Anybody got a 4- or higher-way SMP to try it on? > When I remove the .NOTPARALLEL directives I tested it a bit but I can > certainly believe there are missing dependencies. Maybe I should > start using -j myself... It does make the build significantly faster. Recommended :-) J |
|
From: Tom H. <to...@co...> - 2009-07-16 18:27:48
|
On 16/07/09 00:29, Julian Seward wrote: > On Thursday 16 July 2009, Nicholas Nethercote wrote: >> On Thu, Jul 16, 2009 at 1:39 AM, Tom Hughes<to...@co...> wrote: >>> On 15/07/09 16:40, Julian Seward wrote: >>> >>> Inconsistent failures when using parallel make are usually a sign that >>> there is a dependency missing so that it is trying to run a step before >>> all it's dependencies are satisfied. > > Yes. That's what I was/am afeard of. > > Whatever it is, it's pretty elusive, though. A couple of spins of > "make clean ; make -j 16" produces no problems. This is on a Core 2 > Duo. Anybody got a 4- or higher-way SMP to try it on? I've tried it on 4 and 8 way machines and can't seem to get it to go wrong... Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |