When I added --enable-crypto to the mozconfig file on the Irix tinderbox, I received this error: gmake[2]: Entering directory `/export/tinderbox/SeaMonkey/IRIX_6.5_Depend/mozilla/obj-mips-sgi-irix6.5/security/manager' Makefile:44: /export/tinderbox/SeaMonkey/IRIX_6.5_Depend/mozilla/security/coreconf/IRIX646.5.mk: No such file or directory gmake[2]: *** No rule to make target `/export/tinderbox/SeaMonkey/IRIX_6.5_Depend/mozilla/security/coreconf/IRIX646.5.mk'. Stop. gmake[2]: Leaving directory `/export/tinderbox/SeaMonkey/IRIX_6.5_Depend/mozilla/obj-mips-sgi-irix6.5/security/manager' gmake[1]: *** [export] Error 2 gmake[1]: Leaving directory `/export/tinderbox/SeaMonkey/IRIX_6.5_Depend/mozilla/obj-mips-sgi-irix6.5' gmake: *** [build] Error 2

coreconf/arch.mk converts "IRIX64" to "IRIX" so it is only necessary to have coreconf/IRIX6.5.mk, which already exists. This is an undesirable interaction between mozilla/config/autoconf.mk and coreconf/arch.mk in security/manager/Makefile. coreconf/arch.mk sets OS_TARGET to $(OS_ARCH) only if OS_TARGET is not defined. I bet that your mozilla/config/autoconf.mk sets OS_TARGET to IRIX64. So after coreconf/arch.mk is included, OS_TARGET is still IRIX64. Then security/manager/Makefile attempts to include coreconf/$(OS_CONFIG).mk, where OS_CONFIG is $(OS_TARGET)$(OS_RELEASE). We ran into a similar problem before with OpenVMS. One solution is to ensure that mozilla/config/autoconf.mk and coreconf/arch.mk assign the same value to OS_TARGET. I guess this requires modifying mozilla/configure.in to convert "IRIX64" to "IRIX". A better solution is to modify mozilla/security/manager/Makefile.in so that it can get coreconf's values of DLL_PREFIX, DLL_SUFFIX, and OBJDIR_NAME without including coreconf makefiles. Among these three the most challenging one is OBJDIR_NAME.

mozilla/security/nss/tests/common/Makefile already has an 'objdir_name' target that prints the OBJDIR_NAME value. So mozilla/security/manager/Makefile.in might be able to do something like: CORECONF_OBJDIR:=$(shell $(MAKE) -C ../nss/tests/common --no-print-directory $(OPT_GMAKE_FLAGS) objdir_name) Alternatively, you can add a new makefile in mozilla/security/manager that includes coreconf and has an objdir_name target that echos $(OBJDIR_NAME). By including coreconf in a separate makefile, you isolate mozilla/security/manager/Makefile.in from coreconf. In OPT_GMAKE_FLAGS, you need to pass BUILD_OPT and USE_64, and possible NS_USE_GCC and NS_USE_NATIVE. On Windows you would also need to pass OS_TARGET and USE_DEBUG_RTL, but mozilla/security/manager/Makefile.in is only used by Unix platforms now. As for DLL_PREFIX and DLL_SUFFIX, these should be easy to define by yourself so no need to invoke coreconf to get their values.

*** Bug 81182 has been marked as a duplicate of this bug. ***

Assigning to wtc for review.

David and cls: could you review my patch? It subsumes cls's patch. My patch makes security/manager/Makefile.in entirely independent of coreconf makefiles. There are only three things we need from coreconf. 1. The OBJDIR name that coreconf uses. To get this, I use an existing 'objdir_name' target in an NSS makefile. See how CORECONF_OBJDIR is defined in my patch. 2. DLL_PREFIX. Turns out coreconf itself is not using DLL_PREFIX even though it is defined. So I just use ifdef to deal with it as the DLL_PREFIX is "lib" except on WINNT and OS2. 3. DLL_SUFFIX. mozilla/config/autoconf.mk defines this, so I just use it. I also made sure that we invoke NSS's makefiles with all the make options (cls's patch already has most of these).

r=ddrinan.

My new patch instructs the NSS coreconf build system to install the libs and binaries where Mozilla expects them by overriding the DIST and SOURCE_MD_DIR make variables. This makes coreconf's OBJDIR name irrelevant, and unnecessary for OS/2 to copy the static libs over (bug #72693). It also introduces the MOZILLA_INCLUDES make variable, which Mozilla can use to add arbitrary -I flags to the NSS compile command line.

The latest patch looks correct but doesn't apply cleanly to my tree for some reason. All 3 hunks of mozilla/security/manager/Makefile.in fail.

Ok, scratch that last bit. Once I ran dos2unix on the patch, it worked fine. I have to request another tweak though (to save opening up another trivial bug) so that our non gcc-MD dependencies actually work. Index: mozilla/security/manager/Makefile.in @@ -97,7 +69,7 @@ ifndef MOZ_NSS_AUTOCONF ABS_topsrcdir := $(shell cd $(topsrcdir); pwd) -export:: +depend dependclean export:: $(MAKE) -C ssl $@ $(MAKE) -C pki $@

David, cls, could you review my latest patch again? Thanks.

r=cls

r=javi on latest patch.

Patch checked in.

*** Bug 80662 has been marked as a duplicate of this bug. ***

*** Bug 76740 has been marked as a duplicate of this bug. ***

Verified per wtc's comment.