417044 - (universal-singlepass) less painful universal builds on mac (build universal as a single pass)

Status: RESOLVED WONTFIX

(Firefox Build System :: General, defect, P4)

Description

[(not currently active) Ted Mielczarek]

Since we use the same version of gcc for ppc and x86 now, we could use gcc's intelligent fat binary support to do less painful universal builds.  Essentially you just add -arch <arch> to the cmdline for every architecture you want to target, so we could do like:
CC="gcc -arch i386 -arch ppc"

We'd need to tweak the build system a bit for places where it explicitly checks a target cpu, and figure out some special handling for xptcall's assembly.

Comment 1

[Benjamin Smedberg]

Attachment: NSPR single-pass build, rev. 1

This patch allows NSPR to be built in a single pass, kinda-sorta. It at least should not break the existing two-pass build. Instead of having two separate assembly files and selecting one at configure time via --target, it has a single file and selects the correct assembly internally using defines which are selected at arch-compile time.

Comment 2

[Benjamin Smedberg]

Attachment: Macbuild-singlepass, main tree, WIP

This is a work-in-progress for building mac as a singlepass in the main tree. The patch header has some commentary about the current set of problems: it builds up to PrintPDE currently, but has some interesting configure 'failures'.

Comment 3

[Simon Howes]

Will we also give support for "-arch x86_64" and "-arch ppc64"?

Comment 4

[Benjamin Smedberg]

"support" meaning what? Are we going to make official builds of those variants? Unlikely, at least any time soon. Can you do so? Maybe, if those variants work at all... you'd need to write/copy some assembly for xptcall and NSPR intrinsics, I'd think.

Comment 5

[Robert Kaiser]

Will we get this soon? I think the universal build configuration for bug 437643
 (comm-central repository) would be easier with this, so I'm trying to find out which way to go there.

Comment 6

[Benjamin Smedberg]

I'm not actively working on this

Comment 7

[Wan-Teh Chang]

Comment on attachment 314147 [details] [diff] [review]
NSPR single-pass build, rev. 1

r=wtc.  I'd like to suggest some changes.

We should just remove AC_DEFINE(i386) and AC_DEFINE(ppc)
from configure.in rather than commenting them out.

Instead of adding the inline assembly code to darwin.c,
you can add it to mozilla/nsprpub/pr/include/md/_darwin.h
as macros.  See _linux.h in that directory as an example.
Alternatively, you can create os_Darwin.S (note the capital
S) and use #ifdef in it.  If that doesn't work, use lowercase
s (os_Darwin.s) and define AS as AS='$(CC) -x assembler-with-cpp'
in configure.in.

Comment 8

[Wan-Teh Chang]

I will attach a new NSPR patch next week that implements
the os_Darwin.s approach I suggested.  I found that I can
just define AS=$(CC), which allows me to use C preprocessor
macros in os_Darwin.s.  So the -x assembler-with-cpp flag
isn't necessary.

Comment 9

[Wan-Teh Chang]

Attachment: NSPR's autoconf.mk illustrates potential issues such as MACOSX_DEPLOYMENT_TARGET

There are some potential problems with building a universal
binary in a single pass.  We need to review our configure tests
and makefiles to make sure none of the tests produce different
results for the i386 and ppc architectures.  This review is
error prone.

This attached file is the autoconf.mk file generated by NSPR's
configure script.  You can see that it sets the MACOSX_DEPLOYMENT_TARGET
environment variable to 10.4, which is correct for i386 but wrong
for ppc.  (NSPR still supports 10.2 on ppc.  I'm open to
changing this though.)  This is a good example of this sort.
The file also sets CPU_ARCH and OS_TEST to i386.  So we'd need
to review our makefiles to verify that they don't test these
two variables on the Mac.

So, I hope the pain of the current way of building a universal
binary is worth the effort of reviewing our configure tests
and makefiles to make sure the single-pass method produces the
correct output.

Comment 10

[Wan-Teh Chang]

Attachment: NSPR single-pass build, rev. 2 (checked in)

If we are willing to use #include with non-header files,
we can build NSPR in a single pass with the minimal changes
in this patch.

Most of the changes in this patch are good general cleanup.
gcc -ansi doesn't define "i386", so I changed to test "__i386__"
instead.

Comment 11

[Wan-Teh Chang]

Comment on attachment 330393 [details] [diff] [review]
NSPR single-pass build, rev. 2 (checked in)

I checked in this patch on the NSPR trunk (NSPR 4.7.2).

Comment 12

[Golyc - André Villar]

Ahouks thia be closed after Wan-Teh´s patch ?

Comment 13

[(not currently active) Ted Mielczarek]

wtc's patch implements this only for NSPR, not for the entire Mozilla tree.

I wanted to see what effect this would have on build speeds, so I timed builds of NSPR doing a normal single-architecture build vs. a universal build. I ran (roughly):

configure; time make -j4
real	0m8.837s

CC="gcc -arch ppc -arch i386" configure; time make -j4
real 0m9.880s

So on my macbook pro, it took a whole extra second to build all of NSPR as universal binaries. The whole tree would probably have a bigger win, since there's lots of non-compiling stuff like building chrome jars that we're wasting time on in a universal build.

Comment 14

[Chris Cooper [:coop] (he/him)]

Something for Joey to investigate in Q3.

Comment 15

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

I am adding 674655 as a dependency, since building with "gcc -arch i386 -arch x86_64" will implicitly use the same sdk for both archs.

Comment 16

[Michael Shal [:mshal]]

We no longer do universal builds (bug 1295375).