nsJAR.cpp/nsJAR.h fail to compile with Linux gcc 2.7.2.3

VERIFIED WORKSFORME

Status

defect
P3
normal
VERIFIED WORKSFORME
20 years ago
2 years ago

People

(Reporter: newt, Assigned: samir_bugzilla)

Tracking

Trunk
x86
Linux

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Description

20 years ago
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

Updated

20 years ago
Assignee: dbragg → sgehani

Comment 1

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

Updated

20 years ago
Assignee: sgehani → dbragg
Component: JAR Installation → XPInstall
Assignee

Comment 2

20 years ago
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.
Reporter

Updated

20 years ago
Status: NEW → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
Reporter

Comment 3

20 years ago
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...
Assignee

Updated

20 years ago
Assignee: dbragg → sgehani
Status: RESOLVED → NEW
Assignee

Comment 4

20 years ago
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
Assignee

Updated

20 years ago
Status: NEW → RESOLVED
Last Resolved: 20 years ago20 years ago
Resolution: FIXED → WORKSFORME
Assignee

Comment 5

20 years ago
Worksforme resolution confirmed.

Updated

20 years ago
Status: RESOLVED → VERIFIED

Comment 6

20 years ago
Bulk move of XPInstall (component to be deleted) bugs to Installer: XPInstall
Engine
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.