Since bug 571367 gave us XULRunner universal builds on Snow Leopard slaves we fail to unify at the very end of the compile step: make -f client.mk build in dir /builds/slave/mozilla-central-macosx64-xulrunner/build (timeout 7200 secs) Adding client.mk options from /builds/slave/mozilla-central-macosx64-xulrunner/build/.mozconfig: MOZ_BUILD_PROJECTS=i386 x86_64 .... rm -rf obj-firefox/i386/dist/universal/xulrunner/XUL.framework /builds/slave/mozilla-central-macosx64-xulrunner/build/build/macosx/universal/unify \ --unify-with-sort "\.manifest$" \ --unify-with-sort "components\.list$" \ obj-firefox/i386/dist/xulrunner/XUL.framework \ obj-firefox/x86_64/dist/xulrunner/XUL.framework \ obj-firefox/i386/dist/universal/xulrunner/XUL.framework /builds/slave/mozilla-central-macosx64-xulrunner/build/build/macosx/universal/unify: copyIfIdentical: files differ: obj-firefox/i386/dist/xulrunner/XUL.framework/Versions/2.0b7pre/nspr-config, obj-firefox/x86_64/dist/xulrunner/XUL.framework/Versions/2.0b7pre/nspr-config make[1]: *** [postflight_all] Error 1 diff -u obj-firefox/{i386,x86_64}/dist/xulrunner/XUL.framework/Versions/2.0b7pre/nspr-config --- obj-firefox/i386/dist/xulrunner/XUL.framework/Versions/2.0b7pre/nspr-config 2010-09-27 03:08:55.000000000 -0700 +++ obj-firefox/x86_64/dist/xulrunner/XUL.framework/Versions/2.0b7pre/nspr-config 2010-09-27 04:18:37.000000000 -0700 @@ -132,7 +132,7 @@ if test -n "$lib_nspr"; then libdirs="$libdirs -lnspr${major_version}" fi - os_ldflags=" -isysroot /Developer/SDKs/MacOSX10.5.sdk" + os_ldflags=" -isysroot /Developer/SDKs/MacOSX10.6.sdk" for i in $os_ldflags ; do if echo $i | grep \^-L >/dev/null; then libdirs="$libdirs $i" Bug 558098 might seem similar, but it's for packaging fail on only a 64-bit build.

Blocks 4.0 final ?

Does anyone know why nspr-config is in XUL.framework anyway? It should only be in the SDK, which is not universal AFAIK.

I don't think xulrunner builds block.

This reminds me to the error from Bug 552032, which was very similar. Maybe you can fix this in a similar way?

The build system is supposed to use the 10.5 SDK for i386 and 10.6 SDK for x86_64 so the difference is legit. We already have xulrunner-config in the list of files to exclude from packaging: http://hg.mozilla.org/mozilla-central/file/094d838ed780/xulrunner/installer/mac/Makefile.in#l49 http://hg.mozilla.org/mozilla-central/file/094d838ed780/xulrunner/installer/Makefile.in#l47

This also seems to be breaking packaging of SDK nightlies, which is kinda frustrating.

You are welcome/encouraged to fix it!

Why do we need the 64 bit builds for deploying any MacOS XulRunner builds? Currently we do not have any XulRunner Nightly since 13. Sep 2010 for MacOS X. Why do problems with 64 bit builds cause having no nightlies at all?

Because the build config needs to match Firefox, and is an i386/x86-64 universal build.

If Firefox stuff causes other toolkit based applications to break, then Firefox stuff must be fixed to not break other applications. It is not acceptable that XulRunner for Mac is no longer available since now more than 2 month caused by Firefox.

Georg, if this is a big deal to you here are the steps we use in the failing XULrunner builds. Perhaps you can work up a patch that moves nspr-config into the SDK ? (per comment #2). We have 10.6 machines with XCode 3.2.1, and use this mozconfig http://hg.mozilla.org/build/buildbot-configs/file/default/mozilla2/macosx64/mozilla-central/xulrunner/mozconfig We call make -f client.mk build at the base of the source checkout, with MOZ_OBJDIR=obj-firefox defined in the environment. That is the step which is failing, right at the end when unifying the two architectures into the universal. If you fix that up it would also be worth testing the calls to make -f client.mk sdk # at the base of the source checkout make package # in obj-firefox/i386/

apparently this breaks implementation of the zotero.org citation-manager plug-in which has a fairly wide uptake in the academic community. see discussion here: http://forums.zotero.org/discussion/13363/firefox-4-beta/#Comment_75312

Anyone can do an SDK build. Neither the x86 nor the x86-64 build of the SDK is broken. It's only the unification step which is broken. Please stop commenting on this bug unless you're prepared to write the patch to fix it.

I'm confused on what the right fix should be. The XULRunner runtime is now made as a universal build - it seems the user of the SDK needs to be able to target either i386 or x86_64 (at their discretion). If the user wants to create a universal build of their application - then they would have to perform a similar unify step as is done in the XULRunner build. Is this correct - and if so, how does the user tell the SDK (and ultimately nspr-config) which architecture they wish to target (nspr-config and nspr-config-64)?

The XULRunner *runtime* is universal. But it should not contain the file "nspr-config". The XULRunner *SDK* should not be universal: we should ship separate SDKs for x86 and x86-64 (just as we previously shipped separate SDKs for x86 and PPC).

Moves "nspr-config" from "xulrunner/bin/" to be "xulrunner/sdk/bin/".

Comment on attachment 498278 [details] [diff] [review] Move nspr-config into the xulrunner sdk [Checked in: Comment 28] This looks right, but I'd like somebody to verify that this doesn't break FF-on-XR builds (i.e. --with-libxul-sdk)

Comment on attachment 498278 [details] [diff] [review] Move nspr-config into the xulrunner sdk [Checked in: Comment 28] This works fine.

Can someone please check this patch into mozilla-central?

Comment on attachment 498278 [details] [diff] [review] Move nspr-config into the xulrunner sdk [Checked in: Comment 28] NPOTB

Comment on attachment 498278 [details] [diff] [review] Move nspr-config into the xulrunner sdk [Checked in: Comment 28] I took this patch for a spin on 10.6 and got /builds/slave/cen-osx64-xr/build/build/macosx/universal/unify \ --unify-with-sort "\.manifest$" \ --unify-with-sort "components\.list$" \ obj-firefox/i386/dist/xulrunner/XUL.framework \ obj-firefox/x86_64/dist/xulrunner/XUL.framework \ obj-firefox/i386/dist/universal/xulrunner/XUL.framework /builds/slave/cen-osx64-xr/build/build/macosx/universal/unify: copyIfIdenticalWhenSorted: files differ: obj-firefox/i386/dist/xulrunner/XUL.framework/Versions/2.0b10pre/chrome.manifest, obj-firefox/x86_64/dist/xulrunner/XUL.framework/Versions/2.0b10pre/chrome.manifest make[1]: *** [postflight_all] Error 1 make: *** [build] Error 2 If I diff those two files the x64_64 copy doesn't have a manifest components/nsXULAppInstall.manifest line. If I hack the manifests up then the unify does complete, and I think that's the last thing in 'make build'.

Hi Nick, I can successfully build a universal XULRunner and both SDKs after applying the "nspr-config" patch (just tested it today with latest mozilla-central). OS: 10.6 mozconfig: . $topsrcdir/xulrunner/config/mozconfig . $topsrcdir/build/macosx/universal/mozconfig Did you ensure you used a clean obj- directory?

I removed objdir/*/dist so that might be it. I'll retry with all of the objdir gone. Do you think the configure change will require a clobber for build slaves with existing objdirs for Firefox/T'bird/etc ?

Ok, I don't get the unify error any more. But just afterwards I do get make -C obj-firefox/i386 UNIVERSAL_BINARY= CHROME_JAR= package-tests make[2]: *** No rule to make target `package-tests'. Stop. make[1]: *** [postflight_all] Error 2 make: *** [build] Error 2 Perhaps we should be testing for ENABLE_TESTS=1 at http://mxr.mozilla.org/mozilla-central/source/build/macosx/universal/flight.mk#123 ?

This makes the XULRunner universal build succeed (specifically calling 'make -f client.mk build'). We disable tests there since enabling them doesn't make much sense if you're not going to use them.

Both attachments landed: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=996e407e9735&tochange=e97b4023f672

Success: http://tinderbox.mozilla.org/showlog.cgi?log=XULRunner/1295262214.1295274446.13557.gz http://ftp.mozilla.org/pub/mozilla.org/xulrunner/nightly/2011/01/2011-01-17-03-mozilla-central/ Bug 600931 will probably s/mac64/mac/ in filenames like this: xulrunner-2.0b10pre.en-US.mac64-pkg.dmg (it's really universal, just intel32+intel64 instead of ppc+i386).