User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Firefox/0.10 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Firefox/0.10 I am tryin to build Firefox on Mac OSX, using the instructions on http://www.mozilla.org/projects/firefox/build.html and http://www.mozilla.org/build/mac.html .... I am getting a build error.... ground zero looks like this <snip> make[34]: Entering directory `/mozilla/security/nss/lib/fortcrypt' cd swfort; /usr/bin/make -j1 make[35]: Entering directory `/mozilla/security/nss/lib/fortcrypt/swfort' cd pkcs11; /usr/bin/make -j1 export make[36]: Entering directory `/mozilla/security/nss/lib/fortcrypt/swfort/pkcs11' make[36]: ../../../../../coreconf/arch.mk:58: fork: Resource temporarily unavailable make[36]: ../../../../../coreconf/arch.mk:64: fork: Resource temporarily unavailable make[36]: ../../../../../coreconf/arch.mk:68: fork: Resource temporarily unavailable make[36]: ../../../../../coreconf/arch.mk:145: fork: Resource temporarily unavailable ../../../../../coreconf/config.mk:65: ../../../../../coreconf/.mk: No such file or directory ../../../../../coreconf/config.mk:167: no file name for `-include' make[36]: ../../../../../coreconf/rules.mk:396: fork: Resource temporarily unavailable make[36]: *** No rule to make target `../../../../../coreconf/.mk'. Stop. make[36]: Leaving directory `/mozilla/security/nss/lib/fortcrypt/swfort/pkcs11' <snip> Note the make level is 35/36... i dont know whats happening there .... I am attaching the complete build output (Its done on top of existing object files so its not all the compiles... but a retry from the last build error). I am putting this as a blocker because its preventing me from testing the patch from bug #121540 (The current build that is breaking doesnt have the patch applied.. its just the trunk). Thanx Spundun Reproducible: Always Steps to Reproduce: 1. 2. 3.

The build output is too big to be attached .. so here is a link http://www.isi.edu/~spundun/tmp/mozilla-build-error.txt I also had this environment varialble set export MOZILLA_OFFICIAL=1

A side note.... If there is anyway to get around this error by setting an extra option in the mozconfig file, I dont mind that... I am only trying to test the text rendering in Mozilla/Firefox right now.. Also if you can tell me how can I launch make from where it left, that would be great... make -f client.mk always start right from cvs update.... I am looking for something more akin to make all... so when it breaks I can just enter make all and it will start again from where it left. Thanx Spundun

Is that bug reproducible or just something that you hit once? It looks like the system wasn't able to fork a process to run 'uname' from security/coreconf/arch.mk and that caused the build to fail. Unless the build is choking on the = in your directory name, I don't see how this is a mozilla build bug. Use 'make -f client.mk build_all' to skip the cvs update. That will still start the build from the top of the tree as there's currently no way to pick up from exactly where you left off.

(In reply to comment #3) > Is that bug reproducible or just something that you hit once? I have tried it 4-5 times > It looks like the > system wasn't able to fork a process to run 'uname' from > security/coreconf/arch.mk and that caused the build to fail. Unless the build > is choking on the = in your directory name, I don't see how this is a mozilla > build bug. Hmm .. that is interesting.... I will try to build it by changing the name of the build directory to something else now.. and report the findings here. > > Use 'make -f client.mk build_all' to skip the cvs update. That will still start > the build from the top of the tree as there's currently no way to pick up from > exactly where you left off. Thats exactly what I wanted... thanx. Spundun

OK, I changed the build dir from =build to mozbuild... and then rebuilt and it built and ran (thats thee browser I am using right now to post this). So 90% chance is that its the = in the build dir name thats creating the problem... you can persue this if you want. I lowered the severity to normal. Why I was using =build as a build directory? Becuase I was kinda getting used to the tla standard (The arch version control system) which uses this as a build directory. Anyway I am going further towards my goal. :) Thank you. Spundun

This may be a NSS bug but PSM is the one passing the directories around with =. The rest of the mozilla build system handles it fine.

Downgrading to normal priority.

PSM passes some directory pathnames to NSS like this: DEFAULT_GMAKE_FLAGS += SOURCE_MD_DIR=$(MOZ_BUILD_ROOT)/dist DEFAULT_GMAKE_FLAGS += DIST=$(MOZ_BUILD_ROOT)/dist ... ABS_topsrcdir := $(shell cd $(topsrcdir); pwd) ifneq ($(ABS_topsrcdir),$(MOZ_BUILD_ROOT)) DEFAULT_GMAKE_FLAGS += BUILD_TREE=$(MOZ_BUILD_ROOT) endif Chris, do you think we can defend against a Mozilla build directory pathname containing = by quoting the pathnames we pass to NSS, like this? DEFAULT_GMAKE_FLAGS += SOURCE_MD_DIR="$(MOZ_BUILD_ROOT)/dist" DEFAULT_GMAKE_FLAGS += DIST="$(MOZ_BUILD_ROOT)/dist" ... ABS_topsrcdir := $(shell cd $(topsrcdir); pwd) ifneq ($(ABS_topsrcdir),$(MOZ_BUILD_ROOT)) DEFAULT_GMAKE_FLAGS += BUILD_TREE="$(MOZ_BUILD_ROOT)" endif

We should probably quote those directories anyway but it doesn't seem to make a difference here. make goes into a recursive loop in the fortcrypt directory. The makefile targets in nss/lib/fortcrypt/Makefile contain the full path in an objdir build (maybe srcdir too) so they'll contain the =s as well. When creating the cilib stub library, we're explicitly invoking '$(MAKE) $(STUBLIB)'. The target is being treated as a variable assignment so that command is invoking the default target which is causing a loop.

This patch uses makefile dependencies to build the STUBLIB & STUBDLL instead of explicitly invoking make again. We'll also need to quote at least the MOZILLA_INCLUDES variable being passed to the NSS build in security/manager/Makefile.in .

Chris, thanks a lot for tracking this down. You are indeed a build guru. In security/manager/Makefile.in, we are passing MOZILLA_INCLUDES to NSS like this: MOZILLA_INCLUDES="-I$(MOZ_BUILD_ROOT)/dist/include/nspr -I$(MOZ_BUILD_ROOT)/dist/include/dbm" So I think the MOZILLA_INCLUDES variable is already quoted, right? I regret that I didn't tell you we've cvs removed all the files in security/nss/lib/fortcrypt on the tip of NSS (NSS 3.11), which will land on the Mozilla trunk within two months. So we don't need to patch security/nss/lib/fortcrypt/Makefile. Sorry to have wasted your time. Is security/nss/lib/fortcrypt/Makefile is the only thing in NSS that can't deal with = in directory names? If so, this bug will be fixed as a byproduct of landing NSS 3.11 on the Mozilla trunk, unless we introduced new problems in NSS 3.11.

You are correct. MOZILLA_INCLUDES is already quoted. It wasn't in my makefile due to local modifications. fortcrypt/Makefile is the only place the problem appears in a Firefox build. I haven't tried a standalone NSS build.

I shouldn't work on this, but I can't resist this bug as a brain teaser on a Friday afternoon. Here is my shot at it. I tried to avoid the $(if) function to make the code more readable. I also did some makefile cleanup. It is possible to combine the two $(CILIB) rules into one by creating a new variable for its dependency (which is either $(ORIG_CILIB) or $(STUBLIB)) and the message we echo, but this is enough digression from real work for me

For current steps to reproduce, see bug 1298182 comment 0 and bug 1298182 comment 1.