297688 - Build Camino with gcc 4.0

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[Mark Mentovai]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050613 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050613 Firefox/1.0+

We need to be able to compile Camino using gcc 4.0 on the Mac.  gcc 4.0 is the
default compiler in Xcode 2 shipping with Mac OS X 10.4.  This is one step
toward MacOSX86 support.

Official mozilla.org builds for PPC must continue using gcc 3.3.

The gcc 4.0 that ships with Xcode 2.0 is broken, as discussed many times in the
past.  You must upgrade to Xcode 2.1, which includes a working gcc 4.0.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Mark Mentovai]

Attachment: v1: build Camino with gcc 4, mostly casts

Most of the changes are just casts.  I also needed to change a field from
private to protected in nsMacCursor.  Finally, gcc 3.3 allowed "unsigned in"?

The only thing that maybe could be improved upon is the handling of *ptr in
NetworkServices.mm.  It might be better if there's a single pointer type that
all players could agree on, but that might not really be possible.

Comment 2

[Mike Pinkerton (not reading bugmail)]

one thing to note, not sure how it impacts anything...

we can't easily require xcode 2.1 as it would require everyone to upgrade to
tiger. The project file fomat in 2.1 changes and is not backwards compatible (as
it is for XCode 2.0).

Comment 3

[Mark Mentovai]

No impact, at least not yet.

Comment 4

[Mark Mentovai]

After Josh's build report, I remembered that I should have mentioned something
very important.

You can't build with gcc 4.0 and target an SDK older than 10.3.9.  This is
important for Camino, because the main mozconfig in camino/config/mozconfig
requests the 10.2.8 SDK.  Any attempt to build using that mozconfig and gcc 4.0
is guaranteed to fail.

You can override --with-macos-sdk in your .mozconfig as long as you do it after
you source camino/config/mozconfig.  Here is a minimal example top-level .mozconfig:

--
. $topsrcdir/camino/config/mozconfig
ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.4.0.sdk
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../build-camino
--

I'll have a patch out later to detect undefined SDK-compiler combinations and
error out early during the configure process.

Comment 5

[Josh Aas]

-              menubarParent->GetNativeData ( (void*)menubar );
+              menubarParent->GetNativeData ( (void*&)menubar );

Can you explain that please?

Comment 6

[Mark Mentovai]

(In reply to comment #5)
> -              menubarParent->GetNativeData ( (void*)menubar );
> +              menubarParent->GetNativeData ( (void*&)menubar );
> 
> Can you explain that please?

menubarParent is a nsMenuBarX object, GetNativeData is:

NS_METHOD nsMenuBarX::GetNativeData(void *& aData)
at http://lxr.mozilla.org/mozilla/source/widget/src/cocoa/nsMenuBarX.cpp#684

It would be nicer to use void * throughout, but it comes from the interface:

NS_IMETHOD  GetNativeData(void*& aData) = 0;
at http://lxr.mozilla.org/mozilla/source/widget/public/nsIMenuBar.h#118

and I'm not sure what else, if anything, depends on it.

Comment 7

[Mike Pinkerton (not reading bugmail)]

i *hope* this doesn't get munged internally to

  menubarParent->GetNativeData ( (void*)&menubar );

which is very wrong. You shouldn't have to typecast to a reference type. Casting
to void* should be more than enough. This seems odd. What was the warning/error
here?

Comment 8

[Mark Mentovai]

(In reply to comment #7)
> i *hope* this doesn't get munged internally to
> 
>   menubarParent->GetNativeData ( (void*)&menubar );

Shouldn't be.

> which is very wrong. You shouldn't have to typecast to a reference type.
> Casting to void* should be more than enough. This seems odd. What was the
> warning/error here?

nsMenuX.cpp: In member function 'virtual nsresult
nsMenuX::AttributeChanged(nsIDocument*, PRInt32, nsIAtom*)':
nsMenuX.cpp:1303: error: no matching function for call to
'nsDerivedSafe<nsIMenuBar>::GetNativeData(void*)'
../../../dist/include/widget/nsIMenuBar.h:118: note: candidates are: virtual
nsresult nsIMenuBar::GetNativeData(void*&)

This is weird.  Right now, we have this:

              MenuRef menubar = nsnull;
              menubarParent->GetNativeData ( (void*)menubar );

The cast to void* isn't working, so the proposed fix was to change the cast to
void*&.  But if instead of using a cast, there's an argument of type void*, it
compiles cleanly:

              void *p;
              menubarParent->GetNativeData (p);

Comment 9

[Mark Mentovai]

Attachment: v2

Apparently, the compiler is being overzealous with type checking when there's a
cast involved.	I'm not seeing unwanted address-of with (void*&) casts in test
programs.  Even so, I've decided to make the call with void* and stuff it into
a MenuRef afterwards.  This is the approach taken for Carbon widgets, and it's
working there.

Comment 10

[Josh Aas]

landed on trunk

Comment 11

[Johnnie Menzies]

(In reply to Mark Mentovai from comment #6)

(In reply to comment #5)

•          menubarParent->GetNativeData ( (void*)menubar );
  

•          menubarParent->GetNativeData ( (void*&)menubar );
  

Can you explain that please?

menubarParent is a nsMenuBarX object, GetNativeData is:

NS_METHOD nsMenuBarX::GetNativeData(void & aData)
at http://lxr.mozilla.org/mozilla/source/widget/src/cocoa/nsMenuBarX.cpp#684
https://besthentaigifs.com/
It would be nicer to use void * throughout, but it comes from the interface:
https://bestanimegifs.com/
NS_IMETHOD GetNativeData(void& aData) = 0;
at http://lxr.mozilla.org/mozilla/source/widget/public/nsIMenuBar.h#118

and I'm not sure what else, if anything, depends on it.

thumbs up