Closed Bug 411588 Opened 12 years ago Closed 9 years ago

Support for 64bit universal binaries for Mac OS X

Categories

(Firefox Build System :: General, defect)

PowerPC
macOS
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: simon.bugzilla, Assigned: jaas)

References

Details

(Keywords: 64bit)

Attachments

(2 files, 3 obsolete files)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9b3pre) Gecko/2008010900 Camino/2.0a1pre (like Firefox/3.0b3pre)
Build Identifier: 

To be able to compile Firefox and other Mozilla apps as 32 and 64 bit universal binaries for Mac OS X.

We should at least be able to build as a 64 bit application without errors.

Unsure if there would be a performance gain, however could be good marketing for Mozilla.

Reproducible: Always
Keywords: 64bit
This would be a lot easier with bug 417044 fixed. bsmedberg said he had that mostly working...

Can you build on Mac targetting x86_64? That would be the first step, I'd think.
Does not compile at all.

After 5 seconds of compiling:

nsprpub/config/now.c
gcc-4.2  now.o   -o now
ld: warning in now.o, file is not of required architecture
Undefined symbols:
  "_main", referenced from:
      __start in crt1.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
File that separately (if it's not already), and mark it blocking this bug?
Depends on: 427656
Status: UNCONFIRMED → NEW
Depends on: 370766
No longer depends on: 427656
Ever confirmed: true
Depends on: 468509
No longer depends on: 370766
This bug should be about a universal configuration that includes 64-bit Mac OS X support. 64-bit Mac OS X support itself does not necessarily have to be part of a universal binary. 64-bit Mac OS X support is bug 468509.
On Mac OS X a 32/64-bit Universal application has a checkbox in the Information-View (if you rightclick the application) to choose if the Application should start in 32bit- or 64bit-mode. But I don't know if this must be specified in the application or if this checkbox is a standard if the application contains a 64bit binary.
Some 32/64-bit Universal applications (like XCode 3.0 or Adobe Lightroom 2) have also an <key>LSArchitecturePriority</key> key in its Info.plist to define the priority of the binary architectures. This is not standard, because there are also 32/64-bit Universal applications without this key.
Is it planed to include this in mozilla applications?
We don't use Xcode UI and we have not made any decisions about how we're going to package a universal binary. That is a long ways off.
Since we can build in x86_64 on Mac OS X now, is it now possible in any manner to build a i386/x86_64 binarie? Or are there first some modifications of the build system needed?
And does something like "ac_add_app_options x86_64" exist?
I don't see why it wouldn't be. There's nothing magic about the current universal configuration, it just does ppc/i386 builds in two separate passes, and stitches the results together afterwards. The mozconfig it uses is here:
http://mxr.mozilla.org/mozilla-central/source/build/macosx/universal/mozconfig

You'll notice that that specifies a MOZ_POSTFLIGHT_ALL makefile:
http://mxr.mozilla.org/mozilla-central/source/build/macosx/universal/flight.mk
which is included by client.mk and has its postflight_all target run after both builds complete. That target uses the "unify" script to combine the two builds into a universal build.
Thanks, that was a bit helpfull. I supplemented my mozconfig with /universal/mozconfig and changed all "ppc" to "x86_64". Than I've also changed all "ppc" in /universal/flight.mk to "x86_64". Than the x86_64 part builds just fine, but the i386 part failed, because CROSS_COMPILE=1 was not properly set. So I've set CROSS_COMPILE=1 for all archs. Than it builds just fine in x86_64 and after that in i386. But the flight.mk failed. I get
make[1]: *** [postflight_all] Error 1
make: *** [build] Error 2
But I don't know why, I don't see any other errors. So now I have obj-x86_64-apple-darwin10.2.0/i386/mozilla with the i386 binarie and obj-x86_64-apple-darwin10.2.0/x86_64/mozilla with my x86_64 binarie.
Can you find me on IRC and pastebin me the end of your build log?
Hm, I've never used IRC till now and I had no previous experience with this. But I can email you the end of my build log, if thats OK also...
That's fine, yes.
Depends on: 552032
Attached image Open in 32-bit mode checkbox (obsolete) —
Now I can answer my own question from Comment 5. If you build an i386/x86_64 UB, than you will see the "Open in 32-bit mode" checkbox per default.
(I've added the LSArchitecturePriority key to my Info.plist to set i386 as the default)
I talked with Josh, my plan is to provide another mozconfig in build/macosx/universal that configures things for an i386/x86_64 universal build. I'm going to make it so that it shares most of its core with the existing mozconfig.
Assignee: nobody → ted.mielczarek
Status: NEW → ASSIGNED
This adds a "mozconfig-64" alongside the mozconfig in build/macosx/universal that you can source to do an i386/x86_64 universal build. I made it so both mozconfigs source a common file since it's mostly shared.
Attachment #433183 - Flags: review?(joshmoz)
Attachment #432545 - Attachment is obsolete: true
I've only done a traditional ppc/i386 UB with this, but it built fine.
Attachment #433183 - Flags: review?(joshmoz) → review+
i386/x86_64 build still fails but that is because crashreporter hasn't been ported to x86_64 yet
That might get fixed by jimb's work in bug 517832. bug 548025 covers making everything work natively on 64-bit OSX.
Pushed to m-c:
http://hg.mozilla.org/mozilla-central/rev/af2a60e9e64e
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Crud, I missed a spot:
http://mxr.mozilla.org/mozilla-central/source/build/macosx/universal/flight.mk#42

hardcodes ppc/i386.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Aren't there also hardcoded ppc/i386 lines in unify?
E.g.: http://hg.mozilla.org/mozilla-central/file/ebfe0dc025da/build/macosx/universal/unify#l629
No, those are just variable names.
ted: do you have any ETA on this or scope on how tricky this would be? Its blocking a Q1 goal.
No longer blocks: support-10.6_x64
(In reply to comment #23)
> ted: do you have any ETA on this or scope on how tricky this would be? Its
> blocking a Q1 goal.


per irc with ted and bear just now, we're going to do 64bit-only for now, and will revisit universal builds later after these makefiles are fixed up.
Question. I've wondered why I can't open my 32/64bit Firefox in 32bit. Now I noticed the following warning while building:
> warning: mac68k alignment pragma is deprecated for 64-bit Darwin
Further reading gives me:
>"When compiling 64-bit code, the compiler ignores the pragmas and your code works correctly. If, >however, you currently use the mac68k alignment pragma in your own data structures that will be >shared between 32-bit and 64-bit versions of your application (or if you use the mac68k pragma for >a data structure that corresponds with the register layout of a physical device), you must rewrite the >data structure to use a packed alignment and pad the structure appropriately."
http://developer.apple.com/mac/library/documentation/Darwin/Conceptual/64bitPorting/MakingCode64-BitClean/MakingCode64-BitClean.html

So, could this be the reason?
http://mxr.mozilla.org/mozilla-central/search?string=mac68k
Depends on: 570286
Attached patch flight.mk changes, v1.0 (obsolete) — Splinter Review
Assignee: ted.mielczarek → joshmoz
Attachment #450703 - Flags: review?(ted.mielczarek)
Attached file error with flight.mk changes v1.0 (obsolete) —
I get this error at the end of the build with flight.mk changes v1.0.
Comment on attachment 450703 [details] [diff] [review]
flight.mk changes, v1.0

>diff --git a/build/macosx/universal/flight.mk b/build/macosx/universal/flight.mk
>--- a/build/macosx/universal/flight.mk
>+++ b/build/macosx/universal/flight.mk
>@@ -34,22 +34,22 @@
> #
> # ***** END LICENSE BLOCK *****
> 
> # BE CAREFUL!  This makefile handles a postflight_all rule for a
> # multi-project build, so DON'T rely on anything that might differ between
> # the two OBJDIRs.
> 
> ifndef OBJDIR
>-OBJDIR_PPC = $(MOZ_OBJDIR)/ppc
>-OBJDIR_X86 = $(MOZ_OBJDIR)/i386
>-DIST_PPC = $(OBJDIR_PPC)/dist
>-DIST_X86 = $(OBJDIR_X86)/dist
>-DIST_UNI = $(DIST_PPC)/universal
>-OBJDIR = $(OBJDIR_PPC)
>+OBJDIR_ARCH_1 = $(MOZ_OBJDIR)/$(firstword $(MOZ_BUILD_PROJECTS))
>+OBJDIR_ARCH_2 = $(MOZ_OBJDIR)/$(word 2,$(MOZ_BUILD_PROJECTS))
>+DIST_ARCH_1 = $(OBJDIR_ARCH_1)/dist
>+DIST_ARCH_2 = $(OBJDIR_ARCH_2)/dist
>+DIST_UNI = $(DIST_ARCH_1)/universal
>+OBJDIR = $(DIST_ARCH_1)

This line is the source of your build error. It was originally $(OBJDIR) = $(OBJDIR_PPC), so it should now be $(OBJDIR) = $(OBJDIR_ARCH_1), but you have DIST_ARCH_1.

Looks pretty good otherwise.
Attachment #450703 - Flags: review?(ted.mielczarek) → review-
Ugh, fixed. Thanks.
Attachment #450703 - Attachment is obsolete: true
Attachment #450937 - Attachment is obsolete: true
Attachment #450959 - Flags: review?(ted.mielczarek)
Attachment #450959 - Flags: review?(ted.mielczarek) → review+
pushed to mozilla-central

http://hg.mozilla.org/mozilla-central/rev/f9b239a5a9ef
Status: REOPENED → RESOLVED
Closed: 10 years ago9 years ago
Resolution: --- → FIXED
Blocks: 573244
No longer depends on: 570286
Component: Build Config → General
Product: Firefox → Firefox Build System
You need to log in before you can comment on or make changes to this bug.