Builds fails to create js, libjs.so - version 0.9.6

RESOLVED INCOMPLETE

Status

()

Core
JavaScript Engine
RESOLVED INCOMPLETE
17 years ago
7 years ago

People

(Reporter: Stew Benedict, Unassigned)

Tracking

Trunk
mozilla1.2alpha
PowerPC
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
Building on Mandrake PPC, the build porcess fails to create the above files, due to an error with VARARGS.  The following patch forces it to build:

--- mozilla/js/src/jsprf.c.ppc  Thu Nov 29 13:22:02 2001
+++ mozilla/js/src/jsprf.c      Thu Nov 29 13:33:46 2001
@@ -55,6 +55,9 @@
 #else
 #define VARARGS_ASSIGN(foo, bar)       (foo) = (bar)
 #endif
+#if defined(__powerpc__)
+#define VARARGS_ASSIGN(foo, bar)       foo[0] = bar[0]
+#endif
 
 /*
 ** WARNING: This code may *NOT* call JS_LOG (because JS_LOG calls it)

I tried various mods to configure.in, but was not successful in getting to work at that level.
What version of gcc/glibc does that version of Mandrake PPC use?  The LinuxPPC
(2000?) tinderbox that we have does not see that problem so I don't think
hardcoding that ifdef is the proper fix.
Assignee: seawood → rogerl
Component: Build Config → Javascript Engine
QA Contact: granrose → pschwartau

Comment 2

17 years ago
Formally confirming and reassigning to khanson; cc'ing rginda, jband
as additional reviewers for this patch -
Assignee: rogerl → khanson
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

17 years ago
Created attachment 60476 [details] [diff] [review]
Patch to fix build on Linux PPC platform

This patch fixes the build system, since there is no need to modify source

Comment 4

17 years ago
The problem described can only be seen when building Javascript engin as a
standalone library (using Makefile.ref), not when building in Mozilla seamonkey..

I've attached a clean patch which fix the standalone build rules for Linux PPC

Comment 5

17 years ago
Just need r=, sr= to get this patch in -

Comment 6

17 years ago
Comment on attachment 60476 [details] [diff] [review]
Patch to fix build on Linux PPC platform

r=rginda
Attachment #60476 - Flags: review+

Comment 7

17 years ago
I'm the wrong person to review this. But, like cls suggested, it is not obvious
if this flag is required for all Linux/PPC or if the detection should be more
fine grained to only switch on some particular combination of gcc/glibc
versions. Without additional information there is no way to be sure that this
patch won't help some while hurting others.

Can this patch make things worse?  I'm willing to sr= it if someone can do a
little investigation of under what conditions mozilla/configure.in defines
HAVE_VA_LIST_AS_ARRAY, and then ensure that the same conditions are respected by
the patch.

/be
(Reporter)

Comment 9

17 years ago
Sorry I took so long to get back to you.  Our in-house maintainer has come up
with a patch, which I see he forwarded, which he feels is a better solutions:

In response to the other questions:

[cooker@grapefruit ~/rpm-rebuilder/failure]$ gcc --version
2.95.3
[cooker@grapefruit ~/rpm-rebuilder/failure]$ rpm -q glibc
glibc-2.2.4-15mdk

thx
Stew Benedict


Comment 10

17 years ago
Targeting for 9.9.  Appears that Robert Ginda r= (see comment #6) and Brendan is
willing to sr= (see comment #8).
Target Milestone: --- → mozilla0.9.9

Comment 11

17 years ago
Moved to Mozilla 1.2 as a temporary holding place, as bugs remaining on 0.9.9
are being scrutinized, now that the milestone 
has passed.

If this must be fixed for MachV, then it needs to be assigned the "nsbeta1"
keyword.
Target Milestone: mozilla0.9.9 → mozilla1.2

Comment 12

16 years ago
Any hope to have r= and sr= (post mozilla1.0 of course) ?

As a reminder, this patch doesn't affect mozilla build, only standalone libjs
build..

BTW, could someone with enough privilege add patch keyword to this bug ?

Comment 13

16 years ago
Adding patch keyword as requested.

Have r=, but sr= will require an answer to Brendan's question above:

> Can this patch make things worse?  I'm willing to sr= it if someone can 
> do a little investigation of under what conditions mozilla/configure.in
> defines HAVE_VA_LIST_AS_ARRAY, and then ensure that the same conditions
> are respected by the patch.
Keywords: patch

Comment 14

16 years ago
Oops, I forgot we already had r=..

I've checked mozilla configure.in. HAVE_VA_LIST_AS_ARRAY is defined if
${target_cpu} is ppc..

And that was patch with r= fix (test for CPU_ARCH == ppc) for libjs standalone
build...
The hardcoded HAVE_VA_LIST_AS_ARRAY was for NTO ppc builds.  Further down on
line 1910, there's actually a runtime test.  I don't know why the define is
hardcoded for NTO as the test was explicitly added for NTO (and other platforms)
per bug 20882.

Comment 16

16 years ago
Oops, you're right, I checked configure.in too fast..

So, now we are stuck in a bigger problem : there is a runtime test done by
configure but standalone js engine build doesn't use configure stuff at all :(

Comment 17

13 years ago
Stew, Is this still an issue?
Assignee: khanson → general
QA Contact: pschwartau → general
(In reply to comment #17)
> Stew, Is this still an issue?

Closing this bug after 9 years. I don't have a PPC machine though so please reopen or file a new bug if you're still unable to build the shell.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.