Closed
Bug 79755
Opened 24 years ago
Closed 23 years ago
nsCOMPtr operator== bustage on gcc 2.8.1
Categories
(Core :: XPCOM, defect, P5)
Tracking
()
VERIFIED
WONTFIX
Future
People
(Reporter: jvance, Assigned: dbaron)
Details
Attachments
(2 files)
1.70 KB,
patch
|
Details | Diff | Splinter Review | |
1.90 KB,
patch
|
Details | Diff | Splinter Review |
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
Comment 2•24 years ago
|
||
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
Assignee | ||
Comment 3•24 years ago
|
||
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.
Assignee | ||
Comment 4•24 years ago
|
||
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
Assignee | ||
Comment 5•24 years ago
|
||
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.
Assignee | ||
Comment 7•24 years ago
|
||
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
Assignee | ||
Updated•24 years ago
|
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Assignee | ||
Comment 9•24 years ago
|
||
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
Assignee | ||
Updated•24 years ago
|
Target Milestone: mozilla0.9.3 → Future
Assignee | ||
Comment 10•24 years ago
|
||
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 *)
Assignee | ||
Comment 11•24 years ago
|
||
Assignee | ||
Comment 12•24 years ago
|
||
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!).
Assignee | ||
Comment 13•24 years ago
|
||
Assignee | ||
Updated•24 years ago
|
Target Milestone: Future → mozilla0.9.3
Comment 14•24 years ago
|
||
Yes, I think the caching of the "part 2" test dependent upon the first test will
work. r=cls
Assignee | ||
Comment 15•24 years ago
|
||
Except when I tried on vorlon, the test didn't catch the potential bustage.
Assignee | ||
Updated•24 years ago
|
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Assignee | ||
Updated•24 years ago
|
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Assignee | ||
Updated•24 years ago
|
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Assignee | ||
Updated•24 years ago
|
Target Milestone: mozilla0.9.6 → Future
Assignee | ||
Updated•24 years ago
|
Priority: P4 → P5
Comment 16•24 years ago
|
||
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 :-)
Assignee | ||
Comment 17•23 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•