On both a straight M8 source tarball and a recent CVS -A pull (19990730 21:30 PDT), "make libs" in modules/libjar fails on nsJAR.cpp with the following error in nsJAR.h: c++ -o nsJAR.o -c -fno-rtti -fno-handle-exceptions -Wall -Wconversion -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-align -Woverloaded-virtual -Wsynth -Wp,-MD,.deps/nsJAR.pp -include ../../config-defs.h -g -fPIC -DDEBUG -UNDEBUG -DDEBUG_roelofs -DTRACING -DOSTYPE=\"Linux2.0\" -DNECKO -I../../dist/include -I../../dist/./include -I../../dist/include -I../../include -I/usr/local/experimental/include -I../../dist/./public/jpeg nsJAR.cpp In file included from /usr/include/setjmp.h:36, from ../../include/xp_core.h:293, from ../../include/xp_regexp.h:48, from nsJAR.cpp:34: /usr/include/signal.h:86: warning: `int sigaction(int, struct sigaction *, struct sigaction *)' hides constructor for `struct sigaction' In file included from nsJAR.cpp:39: nsJAR.h:57: warning: conflicting specification deriving virtual function `nsJAR::Find(const char *, nsISimpleEnumerator **)' nsJAR.h:74: parse error before `{' nsJAR.h:76: virtual outside class declaration nsJAR.h:76: virtual outside class declaration nsJAR.h:76: parse error before `protected' nsJAR.h:82: virtual outside class declaration nsJAR.h:83: virtual outside class declaration nsJAR.h:84: virtual outside class declaration nsJAR.h:85: virtual outside class declaration nsJAR.h:87: parse error before `*' nsJAR.h:89: destructors must be member functions nsJAR.h:89: virtual outside class declaration nsJAR.h:89: warning: `void nsJARItem()' hides constructor for `class nsJARItem' nsJAR.h:90: parse error before `}' nsJAR.cpp:59: `NS_IZIP_IID' was not declared in this scope nsJAR.cpp:60: `NS_ZIP_CID' was not declared in this scope [etc.] TenThumbs believes it may have something to do with templates (which, according to comments in include/garray.h, are "problematic" on Unixen and Macs) and worked around it by installing egcs. I have bypassed it for the moment by touching nsJAR.o, nsJARFactory.o and libjar50.so. Neither is particularly satisfactory. My system: Linux 2.0.36, libc5, gcc 2.7.2.3, P100, clobber_all build, configure with no options. Greg Roelofs

Hey Samir. This is the bug I told you about. Reassigning to you per our discussion.

Builds for me with the same compiler on RH5.2, stock kernel 2.0.36. It appears that the IID comes from nsIZip.h which is a generated header (IDL source: nsiZip.idl). The accessor macros that I alluded to this morning were CID accessors and hence probably don't have anything to do with this. Reassiging back to you Don. Given that this doesn't hose any of the Linux tinderboxes I am inclined to vote for worksforme resolution. Your call.

At least in my case, the problem was old copies of nsIJAR.h and nsIZip.h in the libjar directory; for some reason (probably a failed clobber_all that I missed), they didn't get nuked and took precedence over the up-to-date ones in libjar/_xpidlgen . I deleted them and now libjar50.so builds just fine. Sorry for the trouble...

From: Greg Roelofs <newt@pobox.com> 9:59 PM Subject: Re: argh, nsJAR.h is hosing me To: sgehani@netscape.com, tenthumbs@cybernex.net > Do the generated headers (nsIZip.h, nsIJAR.h) have the class and interface ID > accessors defined? Hmmm...apparently not the former; these are the only things that look like accessors in my copies: NS_DEFINE_STATIC_IID_ACCESSOR( NS_IZip_IID ); NS_DEFINE_STATIC_IID_ACCESSOR( NS_IJAR_IID ); BUT WAIT! My files are dated 20 June, which is highly suspicious. And there are two new copies sitting in libjar/_xpidlgen/ ... and when I nuke the ones in libjar, everything works. BARGH, stupid clobber_all must have died before it got that far, and I didn't notice. Thanks... I'll close out bug 11017, then. 10T, let me know if your problem is similar. Greg

Worksforme resolution confirmed.

Bulk move of XPInstall (component to be deleted) bugs to Installer: XPInstall Engine