Closed Bug 1050912 Opened 10 years ago Closed 9 years ago

Intermittent "make[6]: *** No rule to make target `../../../gecko/profile/dirserviceprovider/src/nsProfileLock.cpp', needed by `nsProfileLock.o'. Stop." ("make[5]: *** [toolkit/profile/target] Error 2")

Categories

(Firefox Build System :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: RyanVM, Unassigned)

References

Details

(Keywords: intermittent-failure)

Attachments

(2 files)

https://tbpl.mozilla.org/php/getParsedLog.php?id=45541507&tree=Mozilla-Central

OS X 10.7 mozilla-central non-unified on 2014-08-08 09:05:35 PDT for push 2c56f2d98018
slave: bld-lion-r5-052

make[6]: *** No rule to make target `/builds/slave/m-cen-osx64-nu-000000000000000/build/profile/dirserviceprovider/src/nsProfileLock.cpp', needed by `nsProfileLock.o'.  Stop.
make[5]: *** [toolkit/profile/target] Error 2
make[5]: *** Waiting for unfinished jobs....
https://tbpl.mozilla.org/php/getParsedLog.php?id=45556205&tree=B2g-Inbound
Summary: Intermittent "make: *** [build] Error 2" after "*** No rule to make target `/builds/slave/m-cen-osx64-nu-000000000000000/build/profile/dirserviceprovider/src/nsProfileLock.cpp', needed by `nsProfileLock.o'. Stop." → Intermittent "make: *** [build] Error 2" after "make[6]: *** No rule to make target `../../../gecko/profile/dirserviceprovider/src/nsProfileLock.cpp', needed by `nsProfileLock.o'. Stop."
This is kind of strange.  Presumably it was introduced by http://hg.mozilla.org/mozilla-central/rev/803e2184d7b2
and I imagine its fixed by a clobber.

Given that make believes the file is profile/dirserviceprovider/src/nsProfileLock.cpp not profile/dirserviceprovider/nsProfileLock.cpp it seems like toolkit/profile/backend.mk must be out of date, but that makes no sense because toolkit/profile/moz.build changed, and so presumable config.status should have run and updated that file.
And checking logs configure and config.status both ran.
.deps/*.pp files contain such dependencies... but they should also have empty rules for them to avoid such problems...
I ran into this problem in my local Fennec build after updating my code to include bug 1047878.
Inside my objdir/profile/dirserviceprovider folder:

kats@kgupta-air profile$ find .
.
./backend.mk
./dirserviceprovider
./dirserviceprovider/backend.mk
./dirserviceprovider/Makefile
./dirserviceprovider/src
./dirserviceprovider/src/.deps
./dirserviceprovider/src/.deps/.mkdir.done
./dirserviceprovider/src/.deps/nsProfileDirServiceProvider.o.pp
./dirserviceprovider/src/.deps/nsProfileLock.o.pp
./dirserviceprovider/src/libprofdirserviceprovidersa_s.a.desc
./dirserviceprovider/src/nsProfileDirServiceProvider.o
./dirserviceprovider/src/nsProfileLock.o
./Makefile

And at the top of the nsProfileLock.o.pp file:

nsProfileLock.o: \
 /Users/kats/zspace/mozilla-git/profile/dirserviceprovider/src/nsProfileLock.cpp \

So it looks like in the objdir it didn't recompute the .deps and it's still looking for the old location of the file.

objdir/toolkit/profile/backend.mk has:

CPPSRCS += /Users/kats/zspace/mozilla-git/profile/dirserviceprovider/nsProfileLock.cpp nsToolkitProfileService.cpp

and that's where it's trying to compile it from. Could it be that the toolkit/profile/ folder is compiled before the .deps for the profile/dirserviceprovider folder is regenerated? It seems odd that a makefile in toolkit/profile is pulling in files from other parts of the tree.
Actually even after I did a "mach build profile/dirserviceprovider && rm -rf objdir/profile/dirserviceprovider/src" this error persists. There is a objdir/toolkit/profile/.deps/nsProfileLock.o.pp file which also has a stale dependency for nsProfileLock.o
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #14)
> And at the top of the nsProfileLock.o.pp file:
> 
> nsProfileLock.o: \
>  /Users/kats/zspace/mozilla-git/profile/dirserviceprovider/src/nsProfileLock.
> cpp \


But later in the same file there should be "/Users/kats/zspace/mozilla-git/profile/dirserviceprovider/src/nsProfileLock.cpp:", which is supposed to prevent those errors.
(In reply to Mike Hommey [:glandium] from comment #16)
> But later in the same file there should be
> "/Users/kats/zspace/mozilla-git/profile/dirserviceprovider/src/nsProfileLock.
> cpp:", which is supposed to prevent those errors.

I see no such line in that file. (Although I'm now looking in a different objdir than I was before, because I already clobber-built that one. The one I'm looking in now is also from before the bug 1047878 landing).
From gcc's man page:
  -MP
  This option instructs CPP to add a phony target for each dependency other than
  the main file, causing each to depend on nothing.

So yeah, that would be (sadly) expected, and is why this broke.

But in fact, the problem is not so much that there was no phony target for the main file, but that objdir/toolkit/profile/.deps/nsProfileLock.o.pp has a ref to the old location for the source. The only way this can happen is with ccache, although without CCACHE_BASEDIR, it shouldn't.
Tweaking summary to reduce false positives.
Summary: Intermittent "make: *** [build] Error 2" after "make[6]: *** No rule to make target `../../../gecko/profile/dirserviceprovider/src/nsProfileLock.cpp', needed by `nsProfileLock.o'. Stop." → Intermittent "make[6]: *** No rule to make target `../../../gecko/profile/dirserviceprovider/src/nsProfileLock.cpp', needed by `nsProfileLock.o'. Stop." ("make[5]: *** [toolkit/profile/target] Error 2")
Inactive; closing (see bug 1180138).
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: