The default bug view has changed. See this FAQ.

XULRunner Universal build fails trying to build JavaXPCOM

RESOLVED FIXED

Status

Core Graveyard
Java to XPCOM Bridge
RESOLVED FIXED
11 years ago
3 years ago

People

(Reporter: jhp (no longer active), Assigned: jhp (no longer active))

Tracking

({fixed1.8.0.7, fixed1.8.1})

Trunk
PowerPC
Mac OS X
fixed1.8.0.7, fixed1.8.1

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

11 years ago
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.
(Assignee)

Comment 1

11 years ago
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.
Since the generated files aren't arch-specific, for UB builds we can safely just skip the GenerateJavaInterfaces step during the cross-compile phase.

ifndef CROSS_COMPILE
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 ;-)
(Assignee)

Comment 3

11 years ago
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.
Chances are good that merging doesn't work at all right now... we've never done UB XR builds before, see bug 345047
(Assignee)

Comment 5

11 years ago
Created attachment 234076 [details] [diff] [review]
patch

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.
Attachment #234076 - Flags: review?(benjamin)
Attachment #234076 - Flags: review?(benjamin) → review+
(Assignee)

Comment 6

11 years ago
Checked in to trunk. ->FIXED
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
(Assignee)

Comment 7

11 years ago
Comment on attachment 234076 [details] [diff] [review]
patch

Seeking 1.8.1 approval.  While this patch touches the top level Makefile.in, it is XULRunner only (MOZ_JAVAXPCOM is only defined for XULRunner).
Attachment #234076 - Flags: approval1.8.1?
Comment on attachment 234076 [details] [diff] [review]
patch

a=beltzner on behalf of drivers, please land on MOZILLA_1_8_BRANCH and mark fixed1.8.1
Attachment #234076 - Flags: approval1.8.1? → approval1.8.1+
(Assignee)

Comment 9

11 years ago
Comment on attachment 234076 [details] [diff] [review]
patch

Seeking 1.8.0.7 approval.  This patch is needed (along with the one from bug 345047) for creating Mac Universal builds of XULRunner.
Attachment #234076 - Flags: approval1.8.0.7?
(Assignee)

Comment 10

11 years ago
Checked in to MOZILLA_1_8_BRANCH.
Keywords: fixed1.8.1
Comment on attachment 234076 [details] [diff] [review]
patch

approved for 1.8.0 branch, a=dveditz for drivers
Attachment #234076 - Flags: approval1.8.0.7? → approval1.8.0.7+
(Assignee)

Comment 12

11 years ago
Checked in to MOZILLA_1_8_0_BRANCH.
Keywords: fixed1.8.0.7
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.