602049 - Running universal x86_64/i386 binary on Leopard via command line picks the wrong arch and crashes with "dyld: unknown required load command 0x80000022 Trace/BPT trap"

Status: RESOLVED WONTFIX

(Firefox :: General, defect)

Description

[Nickolay_Ponomarev]

Running universal x86_64/i386 binary on Leopard via command line picks the wrong arch and crashes with "dyld: unknown required load command 0x80000022 Trace/BPT trap", e.g.

$ /Applications/Minefield.app/Contents/MacOS/firefox-bin -no-remote -P
dyld: unknown required load command 0x80000022
Trace/BPT trap
The workaround is to run the command line via "arch -i386 <command>":

$ arch -i386 /Applications/Minefield.app/Contents/MacOS/firefox-bin -no-remote -P

I googled a bit and it seems others have encountered this problem, but the solutions are all not very good - using 10.5 SDK for the 64 bit build or having a wrapper re-launch with the correct arch:
http://www.cocoabuilder.com/archive/xcode/286428-unknown-required-load-command-0x80000022-once-again.html
http://web.archiveorange.com/archive/v/JT06FVCdSjB9ixyOh2Rf (google cache, since the page loads slowly: http://webcache.googleusercontent.com/search?q=cache:Bm2sgRg7HdcJ:web.archiveorange.com/archive/v/JT06FVCdSjB9ixyOh2Rf+dyld:+unknown+required+load+command+universal+command+line&hl=en&client=firefox-a&strip=1 )

Running Firefox from command line is recommended in many places, so if there's anything I missed, it would be great to make this case just work:
http://www.google.com/search?q=%22Firefox.app%22+%22-p%22

If not, I think this deserves a relnote.

Note that this also affects at least the jetpack launcher (cfx run) and likely many other launchers that end up running firefox-bin from the command line.

Comment 1

[(not currently active) Ted Mielczarek]

You can look through the deps on bug 571367 for the zillion other places we fixed this across our codebase.

I don't think there's any general solution to this aside from not shipping universal 32/64 builds. I read the kernel source, and x86-64 is its preferred architecture, and it will load it if present.

Comment 2

[Josh Aas]

We're not planning to make our x86_64 binary compatible with 10.5 or adding a wrapper. We may want to relnote this but it isn't very relevant to the average user. We should definitely document it in developer docs.

We can leave this bug open as a request for documentation but otherwise this is WONTFIX. This does not block bug 571367.

Comment 3

[Nickolay_Ponomarev]

One thing that could be done to fix the command-line case specifically could be: make Contents/MacOS/firefox-bin a wrapper script, but make CFBundleExecutable point to a different name, like firefox-bin64.

Comment 7

[Jarom Loveridge]

As this issue is being rejected I would really like the Mozilla folks to let us know how we are expected to launch their application via the Finder with a specific profile? On Windows it is very easy to do this. On Mac it is downright near impossible. All of the solutions that I have found indicate the necessity to launch from the command-line. That has always been a terribly inelegant solution. Making your 64-bit binary non-compatible with Leopard make the inelegant solutions even worse.

Comment 8

[Ken Winiecki, Jr.]

I agree with Jarom.  But I found an easy way to do it with Applescript.  I use a separate Applescript for each combination of profile and Firefox instance (where multiple instances are given different bundle names such as Firefox_v36.app and Firefox_v40.app).
-----

set appname to "Firefox.app" -- Enter the full name of Firefox bundle to run.
set profnickname to "Johnson_FF40" -- Enter the suffix of profile name to use (for example "9n97fojp.Johnson_FF40").

set firstrun to false
tell application "System Events"
	if file of processes as text does not contain ":" & appname & ":" then
		set firstrun to true
		do shell script "arch -arch i386 /Applications/Firefox/" & appname & "/Contents/MacOS/firefox-bin -P " & profnickname & " -no-remote >& /dev/null & echo $!"
		repeat until (file of processes as text) contains ":" & appname & ":"
			delay 0.06
		end repeat
	end if
end tell

repeat 3 / 0.06 times
	delay 0.06
	try
		tell application appname to activate
		exit repeat
	end try
end repeat

-- Note: the "appname" variable is the only way to keep Applescript from incorrectly second-guessing you when there are multiple instances of Firefox with different bundle names.

-----

Comment 9

[Ken Winiecki, Jr.]

Oops, sorry, probably shouldn't have hardcoded my pathname.  Here is a better one.
-----

set appname to "Firefox.app" -- Enter the full name of Firefox bundle to run.
set apppath to "/Applications" -- Enter the absolute path to the Firefox bundle to run (omitting the trailing slash).
set profnickname to "Johnson_FF40" -- Enter the suffix of profile name to use (for example "9n97fojp.Johnson_FF40").

set firstrun to false
tell application "System Events"
	if file of processes as text does not contain ":" & appname & ":" then
		set firstrun to true
		do shell script "arch -arch i386 & apppath & "/" & appname & "/Contents/MacOS/firefox-bin -P " & profnickname & " -no-remote >& /dev/null & echo $!"
		repeat until (file of processes as text) contains ":" & appname & ":"
			delay 0.06
		end repeat
	end if
end tell

repeat 3 / 0.06 times
	delay 0.06
	try
		tell application appname to activate
		exit repeat
	end try
end repeat

-- Note: the "appname" variable is the only way to keep Applescript from incorrectly second-guessing you when there are multiple instances of Firefox with different bundle names.

-----

Comment 10

[Nickolay_Ponomarev]

FWIW, I posted about various ways to make 'launchers' a while ago: http://asqueella.blogspot.com/2010/01/using-firefox-profiles-on-mac-os-x.html