I updated the version of the Add-on SDK tests run on the central branch this afternoon to address bug 669460 <http://tbpl.mozilla.org/?tree=Firefox&noignore=1&rev=ea752bcac5c5>, after which a Mac 10.5 opt test run reported a cuddlefish.runner.CalledProcessError failure:
Using binary at '/Users/cltbld/talos-slave/test/build/Nightly.app/Contents/MacOS/firefox-bin'.
dyld: unknown required load command 0x80000022
Traceback (most recent call last):
File "bin/cfx", line 29, in <module>
File "/Users/cltbld/talos-slave/test/build/addon-sdk-19b2d58d7fa6/python-lib/cuddlefish/__init__.py", line 487, in run
File "/Users/cltbld/talos-slave/test/build/addon-sdk-19b2d58d7fa6/python-lib/cuddlefish/__init__.py", line 311, in test_all
File "/Users/cltbld/talos-slave/test/build/addon-sdk-19b2d58d7fa6/python-lib/cuddlefish/__init__.py", line 355, in test_all_examples
File "/Users/cltbld/talos-slave/test/build/addon-sdk-19b2d58d7fa6/python-lib/cuddlefish/__init__.py", line 783, in run
File "/Users/cltbld/talos-slave/test/build/addon-sdk-19b2d58d7fa6/python-lib/cuddlefish/runner.py", line 322, in run_app
version_output = check_output([runner.binary, "-v"])
File "/Users/cltbld/talos-slave/test/build/addon-sdk-19b2d58d7fa6/python-lib/cuddlefish/runner.py", line 75, in check_output
raise CalledProcessError(retcode, cmd, output=output)
cuddlefish.runner.CalledProcessError: Command '['/Users/cltbld/talos-slave/test/build/Nightly.app/Contents/MacOS/firefox-bin', '-v']' returned non-zero exit status -5
It isn't clear whether this is a Release Engineering issue or an Add-on SDK one; filing it in the latter bucket for now.
Brian: can you take a look at this one?
http://asqueella.blogspot.com/2010/12/dyld-unknown-required-load-command.html and bug 602049, so, um, whoever it is calling firefox-bin there will probably want to call with arch -i386 on 10.5.
*** Bug 668812 has been marked as a duplicate of this bug. ***
I don't think this is an SDK issue. It looks like the firefox binary being executed is having internal problems, like a dynamic library built for a different OS, ABI, or word length.
If adding an "arch -i386" prefix is the only way around this, hmm, thne I can think of a couple of directions to try:
* modify the SDK's runner.py to know how to add this prefix when on OS-X, maybe in response to some command-line flag. Then also get this flag into run_jetpack.py
* we might be able to trick runner.py into accepting a "--binary" argument which really has "arch -i386" buried in it. Like maybe invoking "cfx testall" with -b "arch -i386 /PATH/TO/FIREFOX" (depends upon the 'cfx' argument parser and how it creates the final command-line argv list). We'd still need to modify run_jetpack.py to pass this funny-looking argument in, and only on OS-X.
But it'd feel more robust if whatever firefox binary we're using could do the right thing by itself.
Per bug 602049, the Firefox binary is not going to change; and who knows if Mac OS X will ever change to resolve this problem; so it looks like we're going to have to implement a workaround in our codebase.
Where we call the binary, can we prepend "arch -i386" automagically if we're running on Mac OS X 10.5? If we do this without a command-line flag, we won't have to modify run_jetpack.py.
Hm, ok, I'll think about that. 1: how to detect we're on 10.5 and not 10.6 (and on OS-X in general, for that matter). 2: how to get a 10.5 box on which I can test this (all my macs are up-to-date). "uname -a" on my 10.6.8 box reports:
Darwin host-6-48.mv.mozilla.com 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 i386
Does anyone know what it reports on a 10.5 box? uname is not my favorite what-platform-are-we-on query, but I don't think python offers anything more sensitive to version-of-the-OS differences.
Looks like Drew just provided a patch in bug 671368: the underlying 10.5 problem was fixed in our copy of mozrunner several months ago, but the -v check wasn't using it. Closing this as a dup now that 671368 is resolved.
*** This bug has been marked as a duplicate of bug 671368 ***