Bug 214235 – Building PDFPlugin.mm with the macOS Big Sur public SDK fails

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: New Bugs

[Rob Buis]

Build fails for PDFPlugin.mm:
PDFPlugin.mm:852:5: error: unknown type name 'CGDataProviderDirectAccessRangesCallbacks'; did you mean 'CGDataProviderDirectCallbacks'?
    CGDataProviderDirectAccessRangesCallbacks dataProviderCallbacks {
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    CGDataProviderDirectCallbacks
In file included from /Users/rwlbuis/work/WebKit/WebKitBuild/Release/DerivedSources/WebKit2/unified-sources/UnifiedSource55-mm.mm:1:
In file included from /Users/rwlbuis/work/WebKit/Source/WebKit/WebKit2Prefix.h:38:
In file included from /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.16.sdk/System/Library/Frameworks/CoreGraphics.framework/Headers/CoreGraphics.h:11:
In file included from /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.16.sdk/System/Library/Frameworks/CoreGraphics.framework/Headers/CGBitmapContext.h:9:
In file included from /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.16.sdk/System/Library/Frameworks/CoreGraphics.framework/Headers/CGContext.h:16:
In file included from /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.16.sdk/System/Library/Frameworks/CoreGraphics.framework/Headers/CGColor.h:15:
In file included from /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.16.sdk/System/Library/Frameworks/CoreGraphics.framework/Headers/CGColorSpace.h:15:
/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.16.sdk/System/Library/Frameworks/CoreGraphics.framework/Headers/CGDataProvider.h:113:46: note: 'CGDataProviderDirectCallbacks' declared here
typedef struct CGDataProviderDirectCallbacks CGDataProviderDirectCallbacks;

[Rob Buis]

Created attachment 404108 [details]
Patch

[Rob Buis]

Created attachment 404111 [details]
Patch

[Darin Adler]

Comment on attachment 404111 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=404111&action=review

> Source/WTF/wtf/PlatformEnableCocoa.h:376
> -#if !defined(ENABLE_PDFKIT_PLUGIN) && PLATFORM(MAC)
> +#if !defined(ENABLE_PDFKIT_PLUGIN) && PLATFORM(MAC) && (USE(APPLE_INTERNAL_SDK) || __MAC_OS_X_VERSION_MIN_REQUIRED < 101600)

This is the wrong solution. I think the correct solution is for us to put the CGDataProviderDirectAccessRangesCallbacks structure into CoreGraphicsSPI.h.

How does this code successfully build on non-Big-Sur macOS?

[Rob Buis]

There were actually more build errors for this file:
In file included from /Users/rwlbuis/work/WebKit/WebKitBuild/Release/DerivedSources/WebKit2/unified-sources/UnifiedSource55-mm.mm:3:
/Users/rwlbuis/work/WebKit/Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm:854:9: error: cannot initialize a member subobject of type 'CGDataProviderGetBytePointerCallback _Nullable'
      (aka 'const void * _Nullable (*)(void * _Nullable)') with an lvalue of type 'size_t (void *, void *, off_t, size_t)' (aka 'unsigned long (void *, void *, long long, unsigned long)'):
      different number of parameters (1 vs 4)
        dataProviderGetBytesAtPositionCallback,
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/rwlbuis/work/WebKit/Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm:855:9: error: cannot initialize a member subobject of type 'CGDataProviderReleaseBytePointerCallback _Nullable'
      (aka 'void (*)(void * _Nullable, const void * _Nonnull)') with an lvalue of type 'void (void *, CFMutableArrayRef, const CFRange *, size_t)' (aka
      'void (void *, __CFArray *, const CFRange *, unsigned long)'): different number of parameters (2 vs 4)
        dataProviderGetByteRangesCallback,
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/rwlbuis/work/WebKit/Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm:856:9: error: cannot initialize a member subobject of type 'CGDataProviderGetBytesAtPositionCallback _Nullable' (aka
      'unsigned long (*)(void * _Nullable, void * _Nonnull, long long, unsigned long)') with an lvalue of type 'void (void *)': different number of parameters (4 vs 1)
        dataProviderReleaseInfoCallback,
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/rwlbuis/work/WebKit/Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm:857:5: error: missing field 'releaseInfo' initializer [-Werror,-Wmissing-field-initializers]
    };
    ^
/Users/rwlbuis/work/WebKit/Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm:868:106: error: use of undeclared identifier 'kCGDataProviderIndeterminateSize'
    RetainPtr<CGDataProviderRef> dataProvider = adoptCF(CGDataProviderCreateMultiRangeDirectAccess(this, kCGDataProviderIndeterminateSize, &dataProviderCallbacks));
                                                                                                         ^
/Users/rwlbuis/work/WebKit/Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm:869:51: error: use of undeclared identifier 'kCGDataProviderHasHighLatency'
    CGDataProviderSetProperty(dataProvider.get(), kCGDataProviderHasHighLatency, kCFBooleanTrue);
                                                  ^
7 errors generated.

[Darin Adler]

Let me ask this question again, before we start making changes to this file:

(In reply to Darin Adler from comment #3)
> How does this code successfully build on non-Big-Sur macOS?

The answer to that will help us understand what we need to do to fix it.

[Rob Buis]

(In reply to Darin Adler from comment #5)
> Let me ask this question again, before we start making changes to this file:
> 
> (In reply to Darin Adler from comment #3)
> > How does this code successfully build on non-Big-Sur macOS?
> 
> The answer to that will help us understand what we need to do to fix it.

Ah, it seems this code was introduced by https://bugs.webkit.org/show_bug.cgi?id=208599, guarded by HAVE_INCREMENTAL_PDF_APIS and then enabled by https://bugs.webkit.org/show_bug.cgi?id=208763.
So possibly disabling HAVE_INCREMENTAL_PDF_APIS for public SDK is the fix here.

I unfortunately have no information on CGDataProviderDirectAccessRangesCallbacks, so for me it is hard to fix it otherwise.

[Darin Adler]

(In reply to Rob Buis from comment #6)
> Ah, it seems this code was introduced by
> https://bugs.webkit.org/show_bug.cgi?id=208599, guarded by
> HAVE_INCREMENTAL_PDF_APIS and then enabled by
> https://bugs.webkit.org/show_bug.cgi?id=208763.

OK, next step is to make a list of things needed from the SPI header for that new HAVE(INCREMENTAL_PDF_APIS) code.

> So possibly disabling HAVE_INCREMENTAL_PDF_APIS for public SDK is the fix
> here.

Disabling features for people who don’t have access to the internal SDK is the absolute last resort. It’s a bad pattern we want to avoid when possible.

> I unfortunately have no information on
> CGDataProviderDirectAccessRangesCallbacks, so for me it is hard to fix it
> otherwise.

Yes, you might either need help from or have the be entirely done by someone from Apple who does have that information. I think Alexey said something about this earlier.

[Rob Buis]

(In reply to Darin Adler from comment #7)
> > So possibly disabling HAVE_INCREMENTAL_PDF_APIS for public SDK is the fix
> > here.
> 
> Disabling features for people who don’t have access to the internal SDK is
> the absolute last resort. It’s a bad pattern we want to avoid when possible.

Sorry, I should have been more clear, I meant disabling it for public SDK, not internal SDK.

[Darin Adler]

(In reply to Rob Buis from comment #8)
> (In reply to Darin Adler from comment #7)
> > > So possibly disabling HAVE_INCREMENTAL_PDF_APIS for public SDK is the fix
> > > here.
> > 
> > Disabling features for people who don’t have access to the internal SDK is
> > the absolute last resort. It’s a bad pattern we want to avoid when possible.
> 
> Sorry, I should have been more clear, I meant disabling it for public SDK,
> not internal SDK.

Yes, that’s what I am talking about (please re-read and note the phrase "don't have access"). We should *not* disable features for public SDK except in unusual circumstances.

[Darin Adler]

Next step is to make a list of things needed from the SPI header for that new HAVE(INCREMENTAL_PDF_APIS) code.

Is there someone who can do that?

[Darin Adler]

Maybe Brady can make that list for us?

[Tim Horton]

Generally jbedard or someone else does this for the whole project at some point during the summer. I'm not sure what the plan is this year, but cc'ing them.

[Jonathan Bedard]

Yeah, there are going to be a ton of things like this, not just for Big Sur, but iOS, watchOS and tvOS too.

Aakash started work on the 2 weeks ago, but I think tvOS and watchOS EWS were a higher priority. Someone from Ops will get this build working in the next 2 weeks, I’ll make sure we keep this bug updated.

[Jonathan Bedard]

Linked this up to https://bugs.webkit.org/show_bug.cgi?id=214396, which should be enough to get WebKit to build for Big Sur with the Seed 1 SDK.

[Rob Buis]

It looks like https://bugs.webkit.org/show_bug.cgi?id=214396 will fix this, so closing this one. Thanks!

*** This bug has been marked as a duplicate of bug 214396 ***