Bug 417044 (universal-singlepass)

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

RESOLVED WONTFIX

Status

Firefox Build System
General
P4
normal
RESOLVED WONTFIX
11 years ago
4 months ago

People

(Reporter: ted, Unassigned)

Tracking

(Depends on: 1 bug)

Trunk
mozilla2.0
x86
Mac OS X
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [buildfaster:p5])

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

11 years ago
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

10 years ago
Created attachment 314147 [details] [diff] [review]
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.
Assignee: nobody → benjamin
Status: NEW → ASSIGNED
Attachment #314147 - Flags: review?

Updated

10 years ago
Alias: universal-singlepass
Summary: less painful universal builds on mac → less painful universal builds on mac (build universal as a single pass)

Comment 2

10 years ago
Created attachment 314157 [details] [diff] [review]
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

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

Comment 4

10 years ago
"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

10 years ago
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

10 years ago
I'm not actively working on this
Assignee: benjamin → nobody
Status: ASSIGNED → NEW

Updated

10 years ago
Attachment #314147 - Flags: review? → review?(wtc)

Comment 7

10 years ago
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.
Attachment #314147 - Flags: review?(wtc) → review+

Comment 8

10 years ago
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

10 years ago
Created attachment 330382 [details]
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

10 years ago
Created attachment 330393 [details] [diff] [review]
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.
Attachment #314147 - Attachment is obsolete: true
Attachment #330393 - Flags: review?(benjamin)

Updated

10 years ago
Attachment #330393 - Flags: review?(benjamin) → review+

Comment 11

10 years ago
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).
Attachment #330393 - Attachment description: NSPR single-pass build, rev. 2 → NSPR single-pass build, rev. 2 (checked in)
Ahouks thia be closed after Wan-Teh´s patch ?
(Reporter)

Comment 13

9 years ago
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.
Something for Joey to investigate in Q3.
Assignee: nobody → joey
Priority: -- → P4

Updated

7 years ago
Whiteboard: [buildfaster:p5]
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.
Depends on: 674655
Depends on: 925167

Updated

5 years ago
Assignee: joey → nobody
We no longer do universal builds (bug 1295375).
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX

Updated

4 months ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.