All users were logged out of Bugzilla on October 13th, 2018

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")

RESOLVED WORKSFORME

Status

RESOLVED WORKSFORME
4 years ago
14 days ago

People

(Reporter: RyanVM, Unassigned)

Tracking

({intermittent-failure})

Trunk
intermittent-failure

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
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....
(Reporter)

Comment 3

4 years ago
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."
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
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.
Comment hidden (Treeherder Robot)
.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).
Created attachment 8471268 [details]
My objdir/profile/dirserviceprovider/src/.deps/nsProfileLock.o.pp
Created attachment 8471269 [details]
My objdir/toolkit/profile/.deps/nsProfileLock.o.pp
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
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
See Also: → bug 1421146

Updated

8 months ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.