On 21/10/13 17:24 , Nathan Froyd wrote:
[Not sure if this is strictly dev-platform material; dev-planning might have
been more appropriate in some respects.]
Our Firefox builds for OS X currently build a 32-bit version, a 64-bit version,
and then squash those together to produce a universal binary that runs on
32-bit or 64-bit systems, as appropriate. This method of building is somewhat
wasteful, as we're building a decent chunk of stuff (chrome JS, etc.) that is
architecture independent.
When targeting OS X, native or cross, clang supports compiling for multiple
architectures in a single pass. Being able to use this capability would likely
speed up our TBPL OS X builds somewhat. (Slowdown in actual compilation would
likely be compensated for by not having to build chrome jars twice, install
headers twice, etc. etc.) However, a variety of issues block being able to do
this, mostly related to a number of places the code where decisions are made
based on whether configure thought we're compiling for a 32-bit or 64-bit
architecture.
I've started poking at some of these issues (bug 925167 and dependents if
you're interested). But various people have pointed out that it only makes
sense to devote resources to this if we're going to be keeping 32-bit OS X
support alive for some time to come. Otherwise, we can just wait a short
amount of time for 32-bit support to be dropped and these issues go away.
How long do we intend to continue shipping a 32-bit Firefox binary on OS X? As
I understand it, we're doing this solely for our OS X 10.6 users, as they are
the only ones potentially running OS X on non-64-bit capable machines.
-Nathan
Additional reason to discuss: this may also affect decisions about how
to ship ICU data, at least on OS X, because it's currently being
duplicated, too.
~ Gijs
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
