Closed Bug 249478 Opened 20 years ago Closed 15 years ago

SpiderMonkey 1.5rc6a compilation errors on Fedora Core2 AMD64

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 163018

People

(Reporter: lsantil, Unassigned)

References

Details

(Keywords: helpwanted) 

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6) Gecko/20040510
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6) Gecko/20040510

On Fedora Core2 for AMD64, the compilation of SpiderMonkey 1.5rc6a fails because
<stdarg.h> is not in /usr/include (nor the other typical directories).  I am not
sure if the error is FC2 specific as many other warnings are also spewed that
could be related to a funky header setup.

Reproducible: Always
Steps to Reproduce:
1. Download js-1.5-rc6a.tar.gz
2. tar zxvf js-1.5-rc6a.tar.gz
3. cd js/src
4. make -f Makefile.ref
Actual Results:  
gcc -o Linux_All_DBG.OBJ/js.o -c -Wall -Wno-format -g -DXP_UNIX -DSVR4 -DSYSV
-D_BSD_SOURCE -DPOSIX_SOURCE -DHAVE_LOCALTIME_R -DHAVE_VA_COPY -DPIC -fPIC 
-DDEBUG -DDEBUG_lpsantil -DEDITLINE -ILinux_All_DBG.OBJ  js.c
gcc -o Linux_All_DBG.OBJ/js -Wall -Wno-format -g -DXP_UNIX -DSVR4 -DSYSV
-D_BSD_SOURCE -DPOSIX_SOURCE -DHAVE_LOCALTIME_R -DHAVE_VA_COPY -DPIC -fPIC 
-DDEBUG -DDEBUG_lpsantil -DEDITLINE -ILinux_All_DBG.OBJ  Linux_All_DBG.OBJ/js.o
Linux_All_DBG.OBJ/libjs.a  -lm -Lfdlibm/Linux_All_DBG.OBJ -lfdm \
    editline/Linux_All_DBG.OBJ/libedit.a
Linux_All_DBG.OBJ/libjs.a(jsprf.o)(.text+0xd83): In function `BuildArgArray':
/home/lpsantil/build/badjs/js/src/jsprf.c:620: undefined reference to `VA_COPY'
collect2: ld returned 1 exit status
make[1]: *** [Linux_All_DBG.OBJ/js] Error 1
make[1]: Leaving directory `/home/lpsantil/build/badjs/js/src'
make: *** [all] Error 2

Full log is here:<https://truthaddict.org/temp/typescript.txt>

Expected Results:  
A compiled version of js shell.

js-1.5-rc6a can be made to compile by modifying line 91 in
js/src/config/Linux_All.mk to be

OS_CFLAGS += -DHAVE_VA_LIST_AS_ARRAY

This solution may be specific to FC2 on AMD64.  A way to detect FC2 on AMD64 may
be needed.
Confirming.

/be
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: DUPEME
According to js/src/config/Linux_All.mk from js-1.5-rc6a (bug 163018), VA_COPY
is a standard macro on x86-64.  Does amd64 not have that macro?  Or is it just
not being expanded because stdarg.h isn't being found for some reason? 
(Wouldn't the compile fail in other places if stdarg.h isn't found at all?) For
Mozilla builds, we define VA_COPY to va_copy or __va_copy.

Bug 248506 is probably related to this bug.

You'd need <stdarg.h> for the varargs stuff. Its not in /usr/include, but the
compliler should be able to find it..

Does a single program with just the #include compile?
Blocks: 237202
Still happens with  1.5rc6a on FC3 x86_64 (and PPC also it seems)

This patch fixes it for both:
http://cvs.fedora.redhat.com/viewcvs/devel/js/js-va_copy.patch?root=extras&rev=1.1&view=markup
Assignee: general → brendan
(In reply to comment #4)
> Still happens with  1.5rc6a on FC3 x86_64 (and PPC also it seems)
> 
> This patch fixes it for both:
>
http://cvs.fedora.redhat.com/viewcvs/devel/js/js-va_copy.patch?root=extras&rev=1.1&view=markup

I'm not so sure this patch would actually fix the problem which may be FC3
x86_64 specific.  The problem for me was that I had set OS_CFLAGS +=
HAVE_VA_LIST_AS_ARRAY (which was contrary to the comment; see link
<http://groups-beta.google.com/group/netscape.public.mozilla.jseng/messages/dac9551eeeb51bf6,d44a77625b7f57be,82d659a1369e8383,01923a2456bd9401,d39d0a7be44dfb7f?thread_id=c2708957bf48d651&mode=thread&noheader=1&q=stdarg+lsantil#doc_dac9551eeeb51bf6>).
   The patch seems to reimplement what was/is already contained in SM but also
adds a fix for Linux PPC.  I haven't installed FC3-x86_64 yet (I decided to go
back to Crux 2.0.1 i686; FC is just so broken for so many packages) so I can't
confirm if this has been fixed in FC3.  Thorsten, please try the HAS_VA_LIST_AS
ARRAY change in the x86_64 ifdef and report back.
(In reply to comment #5)> 
> I'm not so sure this patch would actually fix the problem which may be FC3
> x86_64 specific.
Yes, maybe this is FC3 x86_64. If, I need to report a bug in an other bugzilla ;-)

> Thorsten, please try the HAS_VA_LIST_AS
> ARRAY change in the x86_64 ifdef and report back.
Do you mean OS_CFLAGS +=> -DHAVE_VA_LIST_AS_ARRAY or -DHAS_VA_LIST_AS_ARRAY in
js/src/config/Linux_All.mk? Both do not help :-(
*** Bug 290576 has been marked as a duplicate of this bug. ***
My FC3 has va_copy, not VA_COPY (confirmed by stdarg(3)).  Did the naming change
at some point?

-#define VARARGS_ASSIGN(foo, bar)        VA_COPY(foo,bar)
+#define VARARGS_ASSIGN(foo, bar)        va_copy(foo,bar)

in jsprf.c solves it for me.  (Wanted: one autoconfiscation of the spidermonkey
standalone build.)
Assignee: brendan → shaver
That would also fix FC2, since it also defines va_copy.  Who still needs
VA_COPY, and can we make them munge their config/whatever.mk?
Status: NEW → ASSIGNED
Kinda tempted to check in my change and see who it breaks, since I have not been
able to find anyone that really needs the current capitalization of VA_COPY!
In Mozilla builds, VA_COPY is a macro which expands to va_copy or __va_copy
depending upon the configure test.  The configure test was copied wholesale from
the glib sources (bug 187180) so I'm not sure if we've ever ran into a platform
which only has __va_copy.  If you change it there, you might as well remove the
other 2 uses across the mozilla tree and remove the configure test as well.

 

Ah, but that VA_COPY -> (__)va_copy expansion is clearly not happening for the
standalone JS engine build.  Hrmph.

I am so ready for someone to autoconfiscate that build, I tell ya.
Keywords: helpwanted
Mass abdication.
Assignee: shaver → nobody
Status: ASSIGNED → NEW
QA Contact: pschwartau → general
On Linux platform, already fixed by bug 163018 at 2003.

Dup of it.
Status: NEW → RESOLVED
Closed: 15 years ago
Hardware: x86 → x86_64
Resolution: --- → DUPLICATE
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.