Closed Bug 377730 Opened 13 years ago Closed 9 years ago

xpcwrappedjs.cpp does not build under BeOS

Categories

(Core :: XPCOM, defect)

x86
BeOS
defect
Not set
critical

Tracking

()

RESOLVED WONTFIX

People

(Reporter: doug, Unassigned)

References

Details

(Keywords: helpwanted)

Attachments

(1 file)

mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp fails during build under BeOS.  

Failure is:
c++ -o xpcwrappedjs.o -c  -DXPCOM_TRANSLATE_NSGM_ENTRY_POINT=1 -DMOZILLA_INTERNAL_API -DOSTYPE=\"BeOS6.2\" -DOSARCH=BeOS -DBUILD_ID=0000000000 -DJSFILE -DJS_THREADSAFE -DEXPORT_XPC_API -I/Padauk/home/develop/mozilla/js/src/xpconnect/src/../loader  -I../../../../dist/include/xpcom -I../../../../dist/include/string -I../../../../dist/include/js -I../../../../dist/include/caps -I../../../../dist/include/necko -I../../../../dist/include/dom -I../../../../dist/include   -I../../../../dist/include/xpconnect -I../../../../dist/include/nspr  -DMOZ_PNG_READ -DMOZ_PNG_WRITE  -I../../../../dist/sdk/include       -frtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-multichar -Wno-long-long -pedantic -pipe  -DNDEBUG -DTRIMMED -O2   -DMOZILLA_CLIENT -include ../../../../mozilla-config.h -Wp,-MD,.deps/xpcwrappedjs.pp /Padauk/home/develop/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp
/Padauk/home/develop/mozilla/js/src/xpconnect/src/xpcprivate.h: In method `nsresult nsXPCWrappedJS::cycleCollection::Traverse(nsISupports *, nsCycleCollectionTraversalCallback &)':
/Padauk/home/develop/mozilla/js/src/xpconnect/src/xpcprivate.h:2262: `class nsAutoRefCnt nsXPCWrappedJS::mRefCnt' is protected
/Padauk/home/develop/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp:83: within this context
make[1]: *** [xpcwrappedjs.o] Error 1
make[1]: Leaving directory `/Padauk/home/develop/mozilla/opt-Zeta-cairo/js/src/xpconnect/src'
make: *** [default] Error 2
Assignee: general → nobody
Component: General → XPCOM
Product: Mozilla Application Suite → Core
QA Contact: general → xpcom
Guess is that gcc 2.95 needs internal class to be a friend.
I've looked at the code but I'm having trouble isolating the appropriate "friend class" to add.
Status: NEW → ASSIGNED
Keywords: helpwanted
these three small patches overcome build problems related to nsCycleCollector code on BeOS.
Comment on attachment 262267 [details] [diff] [review]
three one-line changes to overcome this and related bustage

fixes BeOS build bustage introduced by landing 333078.  BeOS gcc doesn't implicitly give "friend" status to internal classes.
Attachment #262267 - Flags: review?(graydon)
Comment on attachment 262267 [details] [diff] [review]
three one-line changes to overcome this and related bustage

Looks fine to me, except you perturbed the backslashes on the end of the macro lines (I think, unless that is a whitespace artifact caused by diff).
Attachment #262267 - Flags: review?(graydon) → review+
Using |friend| in the definition of a class (rather than a declaration) seems odd to me; I'm not sure if there's a reason that we don't do it or just that nobody tried.  (But given that friend declarations don't introduce the name, it seems odd that they could introduce the entire definition.)  The normal pattern for working around this issue for compilers that follow the 1998 C++ standard on this point rather than the 2003 standard is:

  class Inner;
  friend class Inner;
  class Inner {
    // definition
  };
(In reply to comment #6)
> ...snip...
> 
>   class Inner;
>   friend class Inner;
>   class Inner {
>     // definition
>   };
> 

I'll see if I can't rework the fix using this approach, if you think it's more appropriate.


(In reply to comment #6)
> Using |friend| in the definition of a class (rather than a declaration) seems
> odd to me; 

Yes, it is. At least to the code-style in Mozilla. It was a fast way to get round the problem when seeing if that was the problem. It can be done better, unfortunatly my time is a bit limited and I've just given pointers to Doug what needs to be fixed, Doug is mostly managing builds (in an excellent way) so he is not a fullblown developer. 

We know what the problem is now, and how to fix it, although I wouldn't mind if someone added 'friend class ...' where needed. It might even be inside a ifdef 'OLD GCC' to show that it because of us special cases.

(Personally I'd like to see less coding done in ifdef's although lxr is a powerful tool to actually cope with it. I know this is a very special case though) 
This affects a number of compilers, not just gcc.
Blocks: 356310
although I reported the bug, I am no longer involved with the BeOS/Haiku port of Firefox.  Hopefully someone else will take up this bug.
This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.
Status: ASSIGNED → NEW
Flags: in-litmus?
Flags: in-litmus?
BeOS is dead.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.