The default bug view has changed. See this FAQ.

We need to conditionally define the 10.7 Cocoa symbols for 10.6 SDK and lower.

VERIFIED FIXED

Status

()

Core
Widget: Cocoa
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: gandalf, Assigned: smichaud)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Spin off of bug 668953 (see bug 668953 comment 91)

 - we'll need to define 10.7 SDK cocoa symbols when using the 10.6 SDK or lower.
 - we need a way to tell which SDK we're using in compiled
code
(In reply to Zbigniew Braniecki [:gandalf] from comment #0)
>  - we need a way to tell which SDK we're using in compiled code

MAC_OS_X_VERSION_MAX_ALLOWED is exactly that, even though it's very confusingly named. We already use it, for example here:
http://mxr.mozilla.org/mozilla-central/source/widget/src/cocoa/nsCocoaWindow.h#138

Using 
#if !defined(MAC_OS_X_VERSION_10_7) || MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_7
instead of
#ifdef __LP64__
for the enum and interface definitions in nsChildView.h would be exactly the right thing to do here.
(Assignee)

Comment 2

6 years ago
I now agree, Benoit.  I'm about to try it out with a 10.7 SDK build on OS X 10.7.

If that works (which it should), I'll post a patch and ask you to review.
(Assignee)

Comment 3

6 years ago
> I now agree, Benoit.

Oops.  I now agree with both Benoit (bug 668963 comment #98) and Markus.
(Assignee)

Comment 4

6 years ago
Created attachment 552673 [details] [diff] [review]
Fix
Assignee: nobody → smichaud
Attachment #552673 - Flags: review?(bgirard)

Updated

6 years ago
Attachment #552673 - Flags: review?(bgirard) → review+
(Assignee)

Comment 5

6 years ago
Comment on attachment 552673 [details] [diff] [review]
Fix

Landed on mozilla-central:
http://hg.mozilla.org/mozilla-central/rev/5c8b3f1db588
(Assignee)

Updated

6 years ago
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Assignee)

Comment 6

6 years ago
> instead of
> #ifdef __LP64__

As long as we continue to use the 10.5 SDK for 32-bit builds, we can't
use the patch for bug 668953 in 32-bit builds -- the code compiles on
10.6, but won't link.  That's why I used #ifdef __LP64__.

Benoit suggested we might use MAC_OS_X_VERSION_MIN instead.  But I'd
feel obliged to double-check the docs and do test compiles, and we
don't have time for that.  I've	been using __LP64__ all along, and
know that it works.

If we haven't replaced __LP64__ by the time we stop using the 10.5
SDK, we can just drop it -- it'll no	longer be needed.

There's been talk of dropping the 10.5 SDK even before we drop support
for running on OS X 10.5.  See bug 674655.  But this might not work
out.
(In reply to Steven Michaud from comment #6)
> > instead of
> > #ifdef __LP64__
> 
> As long as we continue to use the 10.5 SDK for 32-bit builds, we can't
> use the patch for bug 668953 in 32-bit builds -- the code compiles on
> 10.6, but won't link.

Which part exactly? And why? Have you tested it?
Sorry to be so inquiring, but I'd really like to understand this :)
(Assignee)

Comment 8

6 years ago
It has to do with "blocks".  See bug 668953 comment #67.
Oh, right. I had forgotten that the interface definition has blocks, too (and not only the chunk of code in nsChildView.mm). OK, thanks.
(Reporter)

Comment 10

6 years ago
v.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.