1494851 - -Wunguarded-availability-new error: 'authorizationStatusForMediaType:' is only available on macOS 10.14 or newer

Status: RESOLVED DUPLICATE of bug 1564216

(Core :: Widget: Cocoa, defect, P1)

Description

[Chris Peterson [:cpeterson]]

I can no longer build Firefox after upgrading to macOS 10.14 because I hit -Wunguarded-availability-new warnings-as-errors (in code added in authorizationStatusForMediaType bug 1487204).

 widget/cocoa/nsCocoaUtils.mm:1229:24: error: 'authorizationStatusForMediaType:' is only available on macOS 10.14 or newer [-Werror,-Wunguarded-availability-new]
        [AVCaptureDevice authorizationStatusForMediaType:aMediaType]);
                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /System/Library/Frameworks/AVFoundation.framework/Headers/AVCaptureDevice.h:1479:1: note: 'authorizationStatusForMediaType:' has been explicitly marked partial here
  + (AVAuthorizationStatus)authorizationStatusForMediaType:(AVMediaType)mediaType API_AVAILABLE(macos(10.14), ios(7.0));
  ^
 widget/cocoa/nsCocoaUtils.mm:1229:24: note: enclose 'authorizationStatusForMediaType:' in an @available check to silence this warning
        [AVCaptureDevice authorizationStatusForMediaType:aMediaType]);
                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 widget/cocoa/nsCocoaUtils.mm:1304:19: error: 'AVAuthorizationStatusNotDetermined' is only available on macOS 10.14 or newer [-Werror,-Wunguarded-availability-new]
               (int)AVAuthorizationStatusNotDetermined);

Comment 1

[Haik Aftandilian [:haik]]

Chris, could you post your MOZCONFIG? Have you intentionally enabled -Wunguarded-availability-new yourself?

Comment 2

[Nazım Can Altınova [:canova][:canaltinova on phabricator]]

For the record, cpeterson and I had `ac_add_options --enable-warnings-as-errors` lines in our mozconfig files. Because of that line we were getting that error. Disabling this option fixed the build problem.

Comment 3

[Haik Aftandilian [:haik]]

(In reply to Nazım Can Altınova [:canaltinova] from comment #2)
> For the record, cpeterson and I had `ac_add_options
> --enable-warnings-as-errors` lines in our mozconfig files. Because of that
> line we were getting that error. Disabling this option fixed the build
> problem.

Thanks for the explanation. I'll post a fix so that devs can continue to use the stricter compiler options.

Comment 4

[Haik Aftandilian [:haik]]

Attachment: Patch to address the unguarded availability errors/warnings triggered by nsCocoaUtils.mm on 10.14

This patch wraps the usage of the new 10.14-specific symbols with @available to avoid compiler warnings or errors depending on compiler flags.

Testing these changes is blocked by bug 1494022. Once I can test on 10.14, I'll move forward with landing on Nightly.

Comment 5

[Chris Peterson [:cpeterson]]

(In reply to Haik Aftandilian [:haik] from comment #1)
> Chris, could you post your MOZCONFIG? Have you intentionally enabled
> -Wunguarded-availability-new yourself?

I hadn't intentionally enabled any new warnings. Like Nazım, I had just set `ac_add_options --enable-warnings-as-errors` in my mozconfig.

Comment 6

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: Rebased patch

I ran into this today on my new laptop. Thanks for the patch! It'd bitrotted, so here's a rebased version. Any news on landing it?

I probably won't follow up, since it looks like

ac_add_options --enable-warnings-as-errors

is a lost cause. It compiles futher, but I hit more error-warnings:

2:13.41 /Users/Jan/moz/mozilla-central/toolkit/xre/MacApplicationDelegate.mm:335:47: error: conflicting parameter types in implementation of 'application:continueUserActivity:restorationHandler:': 'void (^ _Nonnull)(NSArray<id<NSUserActivityRestoring>> * _Nonnull)' vs 'void (^ _Nonnull)(NSArray *)' [-Werror,-Wmismatched-parameter-types]
2:13.41 restorationHandler:(void (^)(NSArray *))restorationHandler {

Comment 7

[Mark Banner (:standard8)]

Haik, could we get this reviewed? Is it ready for that?

Comment 8

[Haik Aftandilian [:haik]]

(In reply to Mark Banner (:standard8) from comment #7)

Haik, could we get this reviewed? Is it ready for that?

I didn't originally attempt to land the fix because there was no way to validate the fix on 10.14 due to bug 1494022. That's still true, but I don't think we need to be so cautious. This is low risk and our official builds don't use the 10.14 SDK so not testing with it isn't an issue right now. And I hate to block the use of ac_add_options --enable-warnings-as-errors. I will make sure jib's rebase is still clean and then post this for review.

Note: I assume that anyone hitting this bug is building on 10.14 using the 10.14 SDK (which is the default.) Our official shipping builds are built with the 10.11 SDK. I recommend using the 10.11 SDK so that the build you test with locally will be representative of what our users will use. You can build with the earlier SDK on newer OS versions.

You can get the 10.11 SDK from Xcode 7.3.1 from support.apple.com.

Comment 9

[Haik Aftandilian [:haik]]

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #6)
@jib, could you post your mozconfig? I can't seem to reproduce the build failure with ac_add_options --enable-warnings-as-errors

Comment 10

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

So I too realized after posting this patch that I wasn't going to get anywhere with the 10.14 SDK—some other problem popped up—and I've since added --with-macos-sdk to use 10.13 SDK, and I don't have the problem anymore. Except for that, my mozconfig should be unchanged:

. $topsrcdir/browser/config/mozconfig
ac_add_options --disable-debug
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-x86_64-apple-darwin12.2.1-opt

mk_add_options AUTOCONF=~/bin/autoconf
mk_add_options MOZ_MAKE_FLAGS="-s -j10"
mk_add_options AUTOCLOBBER=1

ac_add_options --with-ccache=/usr/local/bin/ccache
ac_add_options --enable-warnings-as-errors

ac_add_options --with-macos-sdk=/Users/Jan/moz/git/MacOSX-SDKs/MacOSX10.13.sdk

export MOZ_WEBRTC_TESTS=1
export MOZ_WEBRTC_MEDIACONDUIT_TESTS=1
export CCACHE_SLOPPINESS=time_macros,file_macro

export DYLD_LIBRARY_PATH=/Users/Jan/moz/mozilla-central/obj-x86_64-apple-darwin12.2.1-opt/dist/Nightly.app/Contents/MacOS

Comment 11

[:Gijs (he/him)]

Something changed that means I can now no longer build central (on 09d43bf72fa6 ). I'm on 10.13, my mozconfig looks like this:

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../builds/opt

ac_add_options --enable-warnings-as-errors

Errors:

 6:36.06 In file included from path/to/opt/widget/cocoa/Unified_mm_widget_cocoa0.mm:137:
 6:36.06 mozilla-unified/widget/cocoa/nsCocoaUtils.mm:1114:24: error: 'authorizationStatusForMediaType:' is only available on macOS 10.14 or newer [-Werror,-Wunguarded-availability-new]
 6:36.06       [AVCaptureDevice authorizationStatusForMediaType:aMediaType]);
 6:36.06                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 6:36.06 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/AVFoundation.framework/Headers/AVCaptureDevice.h:1479:1: note: 'authorizationStatusForMediaType:' has been marked as being introduced in macOS 10.14 here, but the deployment target is macOS 10.9.0
 6:36.07 + (AVAuthorizationStatus)authorizationStatusForMediaType:(AVMediaType)mediaType API_AVAILABLE(macos(10.14), ios(7.0));
 6:36.07 ^
 6:36.07 mozilla-unified/widget/cocoa/nsCocoaUtils.mm:1114:24: note: enclose 'authorizationStatusForMediaType:' in an @available check to silence this warning
 6:36.07       [AVCaptureDevice authorizationStatusForMediaType:aMediaType]);
 6:36.07                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 6:36.11 mozilla-unified/widget/cocoa/nsCocoaUtils.mm:1209:20: error: 'requestAccessForMediaType:completionHandler:' is only available on macOS 10.14 or newer [-Werror,-Wunguarded-availability-new]
 6:36.11   [AVCaptureDevice requestAccessForMediaType:aType completionHandler:aHandler];
 6:36.11                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 6:36.11 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/AVFoundation.framework/Headers/AVCaptureDevice.h:1502:1: note: 'requestAccessForMediaType:completionHandler:' has been marked as being introduced in macOS 10.14 here, but the deployment target is macOS 10.9.0
 6:36.11 + (void)requestAccessForMediaType:(AVMediaType)mediaType completionHandler:(void (^)(BOOL granted))handler API_AVAILABLE(macos(10.14), ios(7.0));
 6:36.11 ^
 6:36.11 mozilla-unified/widget/cocoa/nsCocoaUtils.mm:1209:20: note: enclose 'requestAccessForMediaType:completionHandler:' in an @available check to silence this warning
 6:36.12   [AVCaptureDevice requestAccessForMediaType:aType completionHandler:aHandler];
 6:36.12                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 6:37.66 2 warnings and 2 errors generated.

Things were fine last week.

Comment 12

[Haik Aftandilian [:haik]]

(In reply to :Gijs (he/him) from comment #11)

Something changed that means I can now no longer build central (on 09d43bf72fa6 ). I'm on 10.13, my mozconfig looks like this:

I'm not aware of anything that could have changed recently to cause this if you were always building with --enable-warnings-as-errors.

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../builds/opt

ac_add_options --enable-warnings-as-errors

Errors:

All the errors appear to be issues resolved by the posted patch that :jib rebased on Comment 6. We should just get this landed.

@:Gijs I'll check the patch hasn't bitrotted further and then would you be willing to test the patch on 10.13?

Comment 13

[:Gijs (he/him)]

(In reply to Haik Aftandilian [:haik] from comment #12)

@:Gijs I'll check the patch hasn't bitrotted further and then would you be willing to test the patch on 10.13?

Sure. Looks like the very first hunk has already been applied (formatting change) but otherwise the patch at least applies sanely. It'll take me an hour or so to verify that this fixes the errors.

Comment 14

[:Gijs (he/him)]

The patch fixes this particular error but builds still fail, now with:

toolkit/xre/MacApplicationDelegate.mm:348:46: error: conflicting parameter types in implementation of 'application:continueUserActivity:restorationHandler:': 'void (^ _Nonnull)(NSArray<id<NSUserActivityRestoring>> * _Nonnull)' vs 'void (^ _Nonnull)(NSArray *)' [-Werror,-Wmismatched-parameter-types]
 4:52.52       restorationHandler:(void (^)(NSArray*))restorationHandler {
 4:52.53                           ~~~~~~~~~~~~~~~~~~ ^
 4:52.55 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSApplication.h:405:187: note: previous definition is here
 4:52.55 - (BOOL)application:(NSApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void(^)(NSArray<id<NSUserActivityRestoring>> *restorableObjects))restorationHandler NS_AVAILABLE_MAC(10_10);

which looks like it's the same as comment 6.

Comment 16

[Andrew McCreight [:mccr8]]

(In reply to :Gijs (he/him) from comment #11)

Things were fine last week.

Yeah, I had the same thing happen, where it just suddenly stopped working in the last week.

Comment 17

[Haik Aftandilian [:haik]]

This was addressed in bug 1564216.