There's another call in ui/gfx/mac/io_surface.cc

https://codereview.chromium.org/2924743002 gets past the build error, but isn't the right fix.

Interesting choice there.

I'll be able to remove those, but I will need a way of finding out what each NSScreen's profile is (either as an ICC profile or parametrically).

> Interesting choice there.

haha - yeah.. The compiler tells you to use this `__builtin_available` thing which isn't documented anywhere, and gives a link error when you try to use it..

I tried it out when the normal redeclare approach didn't work, but I think I had just forgotten to declare it extern "C".

It’s worse than that. They broke this in the 10.13 SDK.

There are two identical functions, CGColorSpaceCopyICCProfile() available since 10.5 and CGColorSpaceCopyICCData() available since 10.12. The old function is supposed to be deprecated and you’re supposed to use the new function. Instead of using the normal deprecation attributes, in the 10.13 SDK that ships with Xcode 9b1 9M136h, you’ll find

  CG_EXTERN CFDataRef __nullable CGColorSpaceCopyICCData(CGColorSpaceRef cg_nullable space)
  CG_AVAILABLE_STARTING(__MAC_10_12, __IPHONE_10_0);

  #define CGColorSpaceCopyICCProfile CGColorSpaceCopyICCData

This forces your compiled code to reference CGColorSpaceCopyICCData() which isn’t available before 10.12 instead of CGColorSpaceCopyICCProfile() which is. -Wpartial-availability catches the problem, but even it didn’t, the result wouldn’t run on 10.11 or earlier, because CGColorSpaceCopyICCData() doesn’t exist there.

I reported this mess as https://openradar.appspot.com/32883726.

I don’t think we need to undertake any major changes here. These functions are identical and it doesn’t appear that Apple intends to deprecate the functionality, they just want to migrate to the newer name and are having a hard time figuring out how to get that to happen in the SDK.

Maybe we should sit on this one for another Xcode beta or two, to see what develops. If we do wind up needing to check in a fix on our end (which we can do, even now, if we want to make it easier for people to work with the 10.13 SDK as it exists today), https://chromium-review.googlesource.com/541020 is more like what we’d want. That lets us keep using CGColorSpaceCopyICCProfile() with any SDK, and it’ll keep using the function by that name at runtime which will work on any OS version.

Thanks mark! I'd be tempted just to land your CL... Apple are limited in their choices to address the regression if they want to still rename this function. I don't think it would conflict in a bad way with whatever they choose, and it would be nice to have HEAD building clean to help dev cycles for fixing problems on 10.13.

I don’t agree that their hands are tied. The normal way to handle this is to deprecate the old and recommend the new as its replacement. I pointed this out in my bug report. Redirecting calls to the new symbol at the source level is actually pretty unprecedented.

But OK, we can land this (or maybe consolidate it into base/mac/sdk_forward_declarations.h) and monitor the radar with an eye to backing the workaround out if they fix the SDK before it’s final.

Ah yep - didn't mean to say they had no other choices. Just that I couldn't think of an alternative choice they would make that would break your CL.

Like you said in the report - the #define approach seems to be critically flawed. Hopefully they fix it.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b68e6af818b39c8a3617c33ce10ec3d3d7af0eb6

commit b68e6af818b39c8a3617c33ce10ec3d3d7af0eb6
Author: Mark Mentovai <mark@chromium.org>
Date: Wed Jun 21 18:42:59 2017

mac: Deal with CGColorSpaceCopyICCProfile() 10.13 SDK bug

Bug:  729896 ,  729895 
Change-Id: I4d5ba4d5c22fc2b85aa14dcde92e02ef3454b9da
Reviewed-on: https://chromium-review.googlesource.com/541020
Reviewed-by: ccameron chromium <ccameron@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Cr-Commit-Position: refs/heads/master@{#481255}
[modify] https://crrev.com/b68e6af818b39c8a3617c33ce10ec3d3d7af0eb6/ui/gfx/icc_profile_mac.mm
[modify] https://crrev.com/b68e6af818b39c8a3617c33ce10ec3d3d7af0eb6/ui/gfx/mac/io_surface.cc

The workaround is checked in, but I’m going to keep this open as a reminder to recheck it as newer versions of the 10.13 SDK beta are released. If things improve (or even just change) before the SDK is final, we may need or want to adjust our strategy.

The radar for this is https://openradar.appspot.com/32883726.

And literally right after I checked this in, Apple released Xcode 9b2 9M137d, whose 10.13 SDK seems to not have this problem.

Looks like I’ll be backing b68e6af818b3 out.

Oh drat :(. Sorry for the bad advice.

Revert: https://chromium-review.googlesource.com/545035/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/861c78b3f9bf6b8804dddbde16002e0c372a11d4

commit 861c78b3f9bf6b8804dddbde16002e0c372a11d4
Author: Mark Mentovai <mark@chromium.org>
Date: Mon Jul 10 20:56:37 2017

Revert "mac: Deal with CGColorSpaceCopyICCProfile() 10.13 SDK bug"

This reverts commit b68e6af818b39c8a3617c33ce10ec3d3d7af0eb6.

The SDK bug that this worked around was fixed in Xcode 9b2 9M137d.

Bug:  729896 
Change-Id: I818ae7b1c0544f7a75281bcdf68192ff14905eec
Reviewed-on: https://chromium-review.googlesource.com/545035
Reviewed-by: Trent Apted <tapted@chromium.org>
Reviewed-by: ccameron chromium <ccameron@chromium.org>
Commit-Queue: ccameron chromium <ccameron@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Cr-Commit-Position: refs/heads/master@{#485378}
[modify] https://crrev.com/861c78b3f9bf6b8804dddbde16002e0c372a11d4/ui/gfx/icc_profile_mac.mm
[modify] https://crrev.com/861c78b3f9bf6b8804dddbde16002e0c372a11d4/ui/gfx/mac/io_surface.cc