Closed Bug 79755 Opened 24 years ago Closed 23 years ago

nsCOMPtr operator== bustage on gcc 2.8.1

Categories

(Core :: XPCOM, defect, P5)

Sun
Solaris
defect

Tracking

()

VERIFIED WONTFIX
Future

People

(Reporter: jvance, Assigned: dbaron)

Details

Attachments

(2 files)

Compiling from 0.9 tarball. using ./configure (no options) gmake (no parameters) compiler is gcc 2.8.1 (2.95.2 and 2.7.x unavailable, as is SPRO) (is this the source of the problem and therefore a duplicate bug?) Error generated: nsRDFContainerUtils.cpp c++ -o nsRDFContainerUtils.o -c -DOSTYPE=\"SunOS5\" -DOSARCH=\"SunOS\" -DMOZ_REFLOW_PERF -DMOZ_REFLOW_PERF_DSP -DOJI -I../../../dist/include -I../../../dist/include -I/export/home3/jvance/downloads/mozilla/dist/include/nspr -I/usr/openwin/include -fPIC -I/usr/openwin/include -fno-rtti -fno-exceptions -pedantic -pipe -DDEBUG -DDEBUG_jvance -DTRACING -g -I/usr/openwin/include -DMOZILLA_CLIENT -include ../../../config-defs.h -Wp,-MD,.deps/nsRDFContainerUtils.pp nsRDFContainerUtils.cpp In file included from ../../../dist/include/nsDebug.h:27, from ../../../dist/include/nsCOMPtr.h:44, from nsRDFContainerUtils.cpp:31: /export/home3/jvance/downloads/mozilla/dist/include/nspr/prtypes.h:318: warning: ANSI C++ does not support `long long' /export/home3/jvance/downloads/mozilla/dist/include/nspr/prtypes.h:319: warning: ANSI C++ does not support `long long' nsRDFContainerUtils.cpp: In method `unsigned int RDFContainerUtilsImpl::IndexOf(class nsIRDFDataSource *, class nsIRDFResource *, class nsIRDFNode *, int *)': nsRDFContainerUtils.cpp:528: ambiguous overload for `nsCOMPtr<nsIRDFResource> & == nsIRDFResource *&' nsRDFContainerUtils.cpp:528: candidates are: operator ==(nsIRDFResource *, nsIRDFResource *) <builtin> ../../../dist/include/nsCOMPtr.h:1166: operator ==<nsIRDFResource, nsIRDFResource>(const nsCOMPtr<nsIRDFResource> &, const nsIRDFResource *) gmake[3]: *** [nsRDFContainerUtils.o] Error 1 gmake[3]: Leaving directory `/export/home3/jvance/downloads/mozilla/rdf/base/src' gmake[2]: *** [install] Error 2 gmake[2]: Leaving directory `/export/home3/jvance/downloads/mozilla/rdf/base' gmake[1]: *** [install] Error 2 gmake[1]: Leaving directory `/export/home3/jvance/downloads/mozilla/rdf' gmake: *** [install] Error 2 I'd like to get this compiled on Solaris and then contribute the binaries. Thx, John Vance
c++ compiler nuances. Reassigning to scc.
Assignee: cls → scc
The line should read if ( source.get() == aContainer ) re-assigning to waterson to fix it (it's his bustage), and cc'ing dbaron as we were under the impression this couldn't happen anymore. You are building with the latest version of "nsCOMPtr.h", are you not? What do you think dbaron?
Assignee: scc → waterson
I'd be interested to see the error in config.log from the test in configure.in for the "ac_nscap_nonconst_opeq_bug". I don't think the solution is fixing the callers... we really should be able to find some solution that works.
Taking this bug since I'd like to find a general solution for this for gcc 2.8.x (although I won't have time in the next few days), and I think there will be many other examples of this in the build. If we manage to fix this, I'm not sure that there won't be other problems compiling with gcc 2.8.x, though... (I know we should compile with gcc 2.7.2.x and with egcs-1.1.2 (gcc 2.91.66) and later (gcc 2.95, "2.96", and 3.0).)
Assignee: waterson → dbaron
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → mozilla0.9.1
The other possibility (if there isn't a better fix) is that --disable-pedantic might fix it (and we could have an autoconf test to force that on compilers broken in this way).
Here's the relevant section of config.log that dbaron asked for: configure:11573: checking for correct overload resolution with const and templates configure:11608: c++ -c -pipe -pedantic -I/usr/openwin/include conftest.C 1>&5 configure: In function `int main()': configure:11603: incomplete type unification configure:11603: ambiguous overload for `Pointer<int> & == const int *&' configure:11589: candidates are: operator ==<int, const int>(const Pointer<int> &, const int *) configure:11595: operator ==<int, int>(const Pointer<int> &, const int *) configure:11605: warning: control reaches end of non-void function `main()' configure: failed program was: #line 11578 "configure" #include "confdefs.h" template <class T> class Pointer { public: T* myPtr; }; template <class T, class U> int operator==(const Pointer<T>& rhs, U* lhs) { return rhs.myPtr == lhs; } template <class T, class U> int operator==(const Pointer<T>& rhs, const U* lhs) { return rhs.myPtr == lhs; } int main() { Pointer<int> foo; const int* bar; return foo == bar; ; return 0; } I will attempt --disable-pedantic next.
Also, in the section of xpcom/base/nsCOMPtr.h beginning with "// Comparing two |nsCOMPtr|s", could you try commenting out the first through the fourth functions and uncommenting the seventh through the tenth (they're essentially commented since that autoconf test fails)?
Compilation completed and mozilla runs after trying --disable-pedantic. Please point me to test cases that hit nsRDFContainerUtilsImpl::IndexOf() so that I can determine whether I compiled a busted executable. If it all works then mark as fixed (I see no category for workaround?) As soon as I get psm compiled and working too I'll contribute the dist for Solaris 2.7
Target Milestone: mozilla0.9.1 → mozilla0.9.2
If it compiles it almost definitely works. (It doesn't matter which of the overloaded operators you get because they all do the same thing in the end.) So since --disable-pedantic is a workaround and it's on a compiler (gcc 2.8.x) we probably don't officially support, pushing this off to 0.9.3, although perhaps I should at least write an autoconf test to tell people to use --disable-pedantic sooner than that...
Severity: blocker → normal
Status: NEW → ASSIGNED
Component: Build Config → XPCOM
Priority: -- → P4
Summary: Compilation fails at nsRDFContainerUtils.cpp → nsCOMPtr operator== bustage on gcc 2.8.1
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Target Milestone: mozilla0.9.3 → Future
egcs 1.0.3 has the same problem, and the error for the autoconf test is: [dbaron@vorlon /tmp]$ g++ comptr-test.cpp comptr-test.cpp: In function `int main()': comptr-test.cpp:24: incomplete type unification comptr-test.cpp:24: ambiguous overload for `Pointer<int> & == const int *&' comptr-test.cpp:10: candidates are: operator ==<int, const int>(const Pointer<int> &, const int *) comptr-test.cpp:16: operator ==<int, int>(const Pointer<int> &, const int *)
cls -- Is this patch reasonable? In particular, will my attempt to cache the value only when the new test succeeds do what I want? If so, I should test this on one of the compilers that fails. I've tested it on gcc 3.0 and gcc 2.7.2.3 and it works as expected with a modification that I'll attach in a second (I missed something!).
Target Milestone: Future → mozilla0.9.3
Yes, I think the caching of the "part 2" test dependent upon the first test will work. r=cls
Except when I tried on vorlon, the test didn't catch the potential bustage.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Target Milestone: mozilla0.9.6 → Future
As the original reporter, I suggest that this be changed to WONTFIX. gcc 2.8.3 is getting ancient, and compiled nightlies are available for Solaris 2.6 that work on my 2.7 box. Let's make this one less bug for Mike Angelo to bitch about :-)
OK, WONTFIX. We don't support gcc 2.7.2.x anymore, so really our minimum gcc compiler requirement is for some version of egcs between 1.0.3 (1998-05-15) (see comment 10) and egcs 1.1.12 (1999-03-15), which is what our nightly builds are *still* done with.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
verified wontfix.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: