Last Comment Bug 348884 - XULRunner Universal build fails trying to build JavaXPCOM
: XULRunner Universal build fails trying to build JavaXPCOM
: fixed1.8.0.7, fixed1.8.1
Product: Core Graveyard
Classification: Graveyard
Component: Java to XPCOM Bridge (show other bugs)
: Trunk
: PowerPC Mac OS X
: -- normal (vote)
: ---
Assigned To: jhp (no longer active)
Depends on:
  Show dependency treegraph
Reported: 2006-08-16 11:51 PDT by jhp (no longer active)
Modified: 2014-09-24 05:43 PDT (History)
3 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---

patch (1.56 KB, patch)
2006-08-16 14:34 PDT, jhp (no longer active)
benjamin: review+
dveditz: approval1.8.0.7+
mbeltzner: approval1.8.1+
Details | Diff | Splinter Review

Description jhp (no longer active) 2006-08-16 11:51:47 PDT
The XULRunner/Mac trunk build is set to build a universal version of XULRunner.  It is failing when trying to run GenerateJavaInterfaces program.  It is trying to run the Intel GenerateJavaInterfaces program on a PPC machine.

I think I need to treat GenerateJavaInterfaces the same way that xpidl is treated when cross compiling.
Comment 1 jhp (no longer active) 2006-08-16 12:45:34 PDT
Actually, it's not as easy as doing what we do for xpidl.  Xpidl is a standalone program that only depends on libxpt (which is also handled differently when cross compiling).  GenerateJavaInterfaces links against the XPCOM and NSPR libs, none of which are built as HOST_LIBS.

Since this problem won't be an issue once we switch to using xpidl for generating Java interfaces (bug 333618), I'm wondering if it wouldn't be best to just put a quick and dirty hack in GenerateJavaInterfaces' Makefile, in order to get this tinderbox building.
Comment 2 Benjamin Smedberg [:bsmedberg] 2006-08-16 12:53:52 PDT
Since the generated files aren't arch-specific, for UB builds we can safely just skip the GenerateJavaInterfaces step during the cross-compile phase.

would work in a makefile

Unfortunately I can't test any patches, since my mac is a mactel and works on both intel and ppc binaries ;-)
Comment 3 jhp (no longer active) 2006-08-16 13:20:29 PDT
Ah, quite right.  Not sure how the merging works if a file is there for one arch but not for the other.  I'll test it right now.
Comment 4 Benjamin Smedberg [:bsmedberg] 2006-08-16 13:21:49 PDT
Chances are good that merging doesn't work at all right now... we've never done UB XR builds before, see bug 345047
Comment 5 jhp (no longer active) 2006-08-16 14:34:16 PDT
Created attachment 234076 [details] [diff] [review]

This patch gets the build past the JavaXPCOM errors I was seeing.  It now fails in xulrunner/installer/mac, but that's probably bug 345047.
Comment 6 jhp (no longer active) 2006-08-17 12:43:52 PDT
Checked in to trunk. ->FIXED
Comment 7 jhp (no longer active) 2006-08-18 08:38:11 PDT
Comment on attachment 234076 [details] [diff] [review]

Seeking 1.8.1 approval.  While this patch touches the top level, it is XULRunner only (MOZ_JAVAXPCOM is only defined for XULRunner).
Comment 8 Mike Beltzner [:beltzner, not reading bugmail] 2006-08-18 10:34:49 PDT
Comment on attachment 234076 [details] [diff] [review]

a=beltzner on behalf of drivers, please land on MOZILLA_1_8_BRANCH and mark fixed1.8.1
Comment 9 jhp (no longer active) 2006-08-23 07:22:25 PDT
Comment on attachment 234076 [details] [diff] [review]

Seeking approval.  This patch is needed (along with the one from bug 345047) for creating Mac Universal builds of XULRunner.
Comment 10 jhp (no longer active) 2006-08-23 12:33:24 PDT
Checked in to MOZILLA_1_8_BRANCH.
Comment 11 Daniel Veditz [:dveditz] 2006-08-23 15:39:57 PDT
Comment on attachment 234076 [details] [diff] [review]

approved for 1.8.0 branch, a=dveditz for drivers
Comment 12 jhp (no longer active) 2006-08-25 09:45:07 PDT
Checked in to MOZILLA_1_8_0_BRANCH.

Note You need to log in before you can comment on or make changes to this bug.