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

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[Stew Benedict]

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.

Comment 1

[hacker formerly known as [e-mail]]

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.

Comment 2

[Phil Schwartau]

Formally confirming and reassigning to khanson; cc'ing rginda, jband
as additional reviewers for this patch -

Comment 3

[Frederic Crozat]

Attachment: Patch to fix build on Linux PPC platform

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

Comment 4

[Frederic Crozat]

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

[Phil Schwartau]

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

Comment 6

[Robert Ginda]

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

r=rginda

Comment 7

[John Bandhauer]

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.

Comment 8

[Brendan Eich [:brendan]]

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

Comment 9

[Stew Benedict]

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

[Kenton Hanson (gone)]

Targeting for 9.9.  Appears that Robert Ginda r= (see comment #6) and Brendan is
willing to sr= (see comment #8).

Comment 11

[Steve Adamski (gone)]

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.

Comment 12

[Frederic Crozat]

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

[Phil Schwartau]

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.

Comment 14

[Frederic Crozat]

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...

Comment 15

[hacker formerly known as [e-mail]]

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

[Frederic Crozat]

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

[Bob Clary [:bc] (inactive)]

Stew, Is this still an issue?

Comment 18

[Jan de Mooij [:jandem]]

(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.