80119 - won't compile due to problems with already_AddRefed

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect, P3)

Description

[eric lindvall]

From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.4.2 i686; Nav)
BuildID:    20010510

when i attempt to compile the mozilla tree with gcc version 2.95.2, it does not
compile cleanly.

Reproducible: Always
Steps to Reproduce:
compile the tree.

Actual Results:  c++ -o nsGenericAccessible.o -c -DOSTYPE=\"Linux2.4\"
-DOSARCH=\"Linux\" -DMOZ_REFLOW_PERF -DMOZ_REFLOW_PERF_DSP -DOJI  
-I../../dist/include -I../../dist/include
-I/usr6/tmp/mozilla/dist/include/nspr      -I/usr/X11R6/include   -fPIC 
-I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion
-Wpointer-arith -Wbad-function-cast -Wcast-align -Woverloaded-virtual -Wsynth
-pedantic -Wno-long-long -pipe -pthread  -DDEBUG -DDEBUG_eric -DTRACING -g
-I/usr/X11R6/include -DMOZILLA_CLIENT -include ../../config-defs.h
-Wp,-MD,.deps/nsGenericAccessible.pp nsGenericAccessible.cpp
nsGenericAccessible.cpp: In method
`nsDOMAccessible::nsDOMAccessible(nsIPresShell *, nsIDOMNode *)':
nsGenericAccessible.cpp:224: cannot convert
`already_AddRefed<nsIWeakReference>()' from type `const
already_AddRefed<nsIWeakReference>' to type `nsIWeakReference *'
make[3]: *** [nsGenericAccessible.o] Error 1

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

Confirming.  I can't actually test this, but I'm wondering if it's not related
to recent already_AddRefed<> changes.

Comment 2

[Leif Hedstrom]

Doesn't look like any of the troubles I had with |already_AddRefed()|. Part of
my problem was that I also had the wrong version of nsCOMPtr.h in my tree, make
sure you have the latest version of this file.

Dmose: That "bug" I experienced earlier was found to be invalid, no changes was
done to nsCOMPtr.h as far as I know.

Comment 3

[Scott Collins]

You have to say |.get()| to assign the value from an |already_AddRefed<T>| into
a raw |T*|.  This has been the case since the fix for bug #75504.  I fixed all
callers in the tree.  Are you up to date?  Just to summarize ... the change was
transparent when assigning into an |nsCOMPtr|, but now to assign into a raw
pointer, |.get()| must be used.  The current version of this file is 1.2.  That
line should read

  mPresShell = do_GetWeakReference(aShell);

...is that what you see?

Comment 4

[Scott Collins]

`this file' of course refers to the file reported in the error, that is
"nsGenericAccessible.cpp", the line is 224

Comment 5

[eric lindvall]

i had downloaded the mozilla 0.9 tarball, and followed the instructions for
upgrading to the latest cvs:
run "cvs -z3 checkout -PA mozilla/client.mk" and "make -f mozilla/client.mk
checkout MOZ_CO_FLAGS=-PA".

dispite this, the makefile only runs:
cvs -d :pserver:[e-mail]:/cvsroot -q -z 3 co -P
mozilla/accessible
cvs -d :pserver:[e-mail]:/cvsroot -q -z 3 co -P
mozilla/gfx2
cvs -d :pserver:[e-mail]:/cvsroot -q -z 3 co -P
mozilla/modules/libpr0n

it seems that the tags were not reset, and i had an old version of
nsGenericAccessible.cpp. it looks like the problem was really with the build
scripts.

Comment 6

[Scott Collins]

OK, so do we need to fix the 0.9 tarball?  Leaf?

Comment 7

[Daniel (Leaf) Nunes]

no, we just need to find a workaround to using the script in the way specified;
or, even better, use a current source tarball. If the reporter finds using a
trunk tarball acceptable, please comment in the bug.

Comment 8

[eric lindvall]

i may be wrong, but i assumed the problem was in mozilla/client.mk not leaving
the MOZ_CO_FLAGS as they should be. at line 244 (and the next couple) it ignores
the CVS_CO_FLAGS and sets it's own, which means that even if you attempt to
force it to clear the tags, it will not.

if you were to check and make sure that if there is not a _CO_TAG set, it would
set the _CO_FLAGS to include what MOZ_CO_FLAGS contains.

Comment 9

[Daniel (Leaf) Nunes]

I think you're right, that this needs to be fixed. However, i don't think this
is going to be fixed in the 0.9 tarball.

Comment 10

[eric lindvall]

it doesn't need to be. the first line in those two lines pulls the latest
client.mk from the cvs tree, which means that anyone who tries to build after it
has been fixed will have a working tree.

Comment 11

[Daniel (Leaf) Nunes]

Attachment: make sure we keep track of existing CVS_CO_FLAGS when setting MOZ_CO_TAG

Comment 12

[Daniel (Leaf) Nunes]

can i get a witness? or an r=?

Comment 13

[Daniel (Leaf) Nunes]

cls pointed out to me tonight that recently client.mk was fixed so that having
MOZ_CO_FLAGS set (for instance, in this case, with -PA) would still have those
options passed to the checkout command, rendering my patch obsolete, though the
environment variable you need to define is different.

resolving fixed.