Closed Bug 600435 Opened 9 years ago Closed 9 years ago

XULRunner universal for i386/x64_64 fails to unify nspr-config


(Firefox Build System :: General, defect)

Not set


(blocking2.0 -)

Tracking Status
blocking2.0 --- -


(Reporter: nthomas, Assigned: twhitema)




(2 files)

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 build
 in dir /builds/slave/mozilla-central-macosx64-xulrunner/build (timeout 7200 secs)
Adding 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 \
/builds/slave/mozilla-central-macosx64-xulrunner/build/build/macosx/universal/unify: copyIfIdentical: files differ:
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}"
-      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 ?
blocking2.0: --- → ?
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.
blocking2.0: ? → -
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:
Duplicate of this bug: 608535
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
We call
 make -f 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 sdk    # at the base of the source checkout
 make package             # in obj-firefox/i386/
apparently this breaks implementation of the citation-manager plug-in which has a fairly wide uptake in the academic community. see discussion here:
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).
Duplicate of this bug: 619686
Moves "nspr-config" from "xulrunner/bin/" to be "xulrunner/sdk/bin/".
Attachment #498278 - Flags: review?(benjamin)
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)
Attachment #498278 - Flags: review?(mh+mozilla)
Attachment #498278 - Flags: review?(benjamin)
Attachment #498278 - Flags: review+
Comment on attachment 498278 [details] [diff] [review]
Move nspr-config into the xulrunner sdk
[Checked in: Comment 28]

This works fine.
Attachment #498278 - Flags: review?(mh+mozilla) → review+
Can someone please check this patch into mozilla-central?
Attachment #498278 - Flags: approval2.0?
Comment on attachment 498278 [details] [diff] [review]
Move nspr-config into the xulrunner sdk
[Checked in: Comment 28]

Attachment #498278 - Flags: approval2.0?
Keywords: checkin-needed
Blocks: 624860
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 \
/builds/slave/cen-osx64-xr/build/build/macosx/universal/unify: copyIfIdenticalWhenSorted: files differ:
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'.
No longer blocks: 624860
Assignee: nobody → toddw
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
    . $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 ?
This makes the XULRunner universal build succeed (specifically calling 'make -f build'). We disable tests there since enabling them doesn't make much sense if you're not going to use them.
Attachment #503736 - Flags: review?(khuey)
Version: unspecified → Trunk
Version: unspecified → Trunk
Attachment #498278 - Attachment description: Move nspr-config into the xulrunner sdk → Move nspr-config into the xulrunner sdk [Checked in: Comment 28]
Attachment #503736 - Attachment description: Make packaging tests properly conditional for universal builds → Make packaging tests properly conditional for universal builds [Checked in: Comment 28]

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).
Closed: 9 years ago
Resolution: --- → FIXED
Flags: in-testsuite-
Target Milestone: --- → mozilla2.0b10
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.