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

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?

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

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

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?

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.

Mass abdication.

On Linux platform, already fixed by bug 163018 at 2003. Dup of it.