27.42 KB, patch
|Details | Diff | Splinter Review|
2.45 KB, text/plain
4.33 KB, patch
Benjamin Smedberg: 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.
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?
Summary: less painful universal builds on mac → less painful universal builds on mac (build universal as a single pass)
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'.
Will we also give support for "-arch x86_64" and "-arch ppc64"?
"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.
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.
I'm not actively working on this
Assignee: benjamin → nobody
Status: ASSIGNED → NEW
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+
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.
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.
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.
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 ?
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
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
We no longer do universal builds (bug 1295375).
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.