Closed
Bug 417044
(universal-singlepass)
Opened 17 years ago
Closed 8 years ago
less painful universal builds on mac (build universal as a single pass)
Categories
(Firefox Build System :: General, defect, P4)
Tracking
(Not tracked)
RESOLVED
WONTFIX
mozilla2.0
People
(Reporter: ted, Unassigned)
References
(Depends on 1 open bug)
Details
(Whiteboard: [buildfaster:p5])
Attachments
(3 files, 1 obsolete file)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
benjamin
:
review+
|
Details | Diff | Splinter Review |
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•17 years ago
|
||
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.
Updated•17 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•17 years ago
|
||
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•17 years ago
|
||
Will we also give support for "-arch x86_64" and "-arch ppc64"?
Comment 4•17 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•16 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•16 years ago
|
||
I'm not actively working on this
Assignee: benjamin → nobody
Status: ASSIGNED → NEW
Updated•16 years ago
|
Attachment #314147 -
Flags: review? → review?(wtc)
Comment 7•16 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•16 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•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
Attachment #330393 -
Flags: review?(benjamin) → review+
Comment 11•16 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)
Comment 12•15 years ago
|
||
Ahouks thia be closed after Wan-Teh´s patch ?
Reporter | ||
Comment 13•15 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.
Comment 14•13 years ago
|
||
Something for Joey to investigate in Q3.
Assignee: nobody → joey
Priority: -- → P4
Updated•13 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: 781171
Updated•11 years ago
|
Assignee: joey → nobody
Comment 16•8 years ago
|
||
We no longer do universal builds (bug 1295375).
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Updated•7 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•