Bug 155931 – Cannot build WebKit for iOS device using Xcode 7.3/iOS 9.3 public SDK due to missing private frameworks and libraries

• Component: WebKit Misc.
• Status: RESOLVED FIXED

[Hofi]

During the command line build of webkit on osx 10.11.4 box as an ios device target using Xcode 7.3 final the next error happens

Ld /Users/hofi/Develop/Others/WebKit/WebKitBuild/Release-iphoneos/WebCore.framework/WebCore normal arm64
    cd /Users/hofi/Develop/Others/WebKit/Source/WebCore
    export IPHONEOS_DEPLOYMENT_TARGET=9.3
    export PATH="/xcode_7_3/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/xcode_7_3/Xcode.app/Contents/Developer/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
    /xcode_7_3/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -arch arm64 -dynamiclib -isysroot /xcode_7_3/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS9.3.sdk -L/Users/hofi/Develop/Others/WebKit/WebKitBuild/Release-iphoneos -F/Users/hofi/Develop/Others/WebKit/WebKitBuild/Release-iphoneos -F/xcode_7_3/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS9.3.sdk/System/Library/PrivateFrameworks -filelist /Users/hofi/Develop/Others/WebKit/WebKitBuild/WebCore.build/Release-iphoneos/WebCore.build/Objects-normal/arm64/WebCore.LinkFileList -unexported_symbols_list Configurations/WebCore.unexp -install_name /System/Library/PrivateFrameworks/WebCore.framework/WebCore -miphoneos-version-min=9.3 -dead_strip -lsqlite3 -lobjc -lANGLE -framework CFNetwork -framework CoreGraphics -framework CoreText -framework Foundation -framework GraphicsServices -framework ImageIO -framework OpenGLES -lMobileGestalt -framework IOSurface -stdlib=libc++ -fobjc-link-runtime -framework Accelerate -framework AudioToolbox -framework CoreAudio -framework IOKit -framework JavaScriptCore -licucore -lobjc -lxml2 -lz -framework QuartzCore -framework Security -framework SystemConfiguration -single_module -compatibility_version 1 -current_version 602.1.26 -Xlinker -dependency_info -Xlinker /Users/hofi/Develop/Others/WebKit/WebKitBuild/WebCore.build/Release-iphoneos/WebCore.build/Objects-normal/arm64/WebCore_dependency_info.dat -o /Users/hofi/Develop/Others/WebKit/WebKitBuild/Release-iphoneos/WebCore.framework/WebCore
ld: warning: directory not found for option '-F/xcode_7_3/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS9.3.sdk/System/Library/PrivateFrameworks'
ld: framework not found GraphicsServices
clang: error: linker command failed with exit code 1 (use -v to see invocation)
** BUILD FAILED **


there is no Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS9.3.sdk/System/Library/PrivateFrameworks folder in Xcode7.3

The source was the latest svn version after running the update-webkit with version info

Repository Root: https://svn.webkit.org/repository/webkit
Repository UUID: 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Revision: 198685
Node Kind: directory
Schedule: normal
Last Changed Author: [e-mail]
Last Changed Rev: 198684
Last Changed Date: 2016-03-25 20:32:53 +0100 (Fri, 25 Mar 2016)

[Daniel Bates]

From briefly searching through the various .xccconfig files in the repository, we depend on the following iphoneos private frameworks that are not included with Xcode 7.3/iOS 9.3 public SDK:

AssertionServices
CorePDF
GraphicsServices
IOSurface

We also depend on the following iphoneos libraries that are not included with Xcode 7.3/iOS 9.3 public SDK: 

MobileGestalt
Accessibility

[Radar WebKit Bug Importer]

<rdar://problem/25807989>

[Daniel Bates]

Created attachment 285916 [details]
Patch

[Daniel Bates]

Created attachment 285948 [details]
Patch

As suggested by Dan Bernstein, prefixed added custom Xcode build variables with "WK_" so as to make them stand out from the standard Xcode build variables. Also changed "--- !tapi-tbd-v2" to "---" in the iOS 9 .tbd files in an attempt to make the iOS EWS happy.

[Daniel Bates]

Created attachment 285978 [details]
Patch

[Daniel Bates]

Created attachment 285992 [details]
Patch

Attempt to fix up format of iOS 9 .tbd files to make ld(1), included in Xcode 7.3.1 (7D1014), happy.

Comment on attachment 285992 [details]
Patch

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

> Source/JavaScriptCore/Configurations/Base.xcconfig:107
> +FRAMEWORK_SEARCH_PATHS_base = $(WK_QUOTED_OVERRIDE_FRAMEWORKS_DIR);
> +FRAMEWORK_SEARCH_PATHS[sdk=iphone*] = $(FRAMEWORK_SEARCH_PATHS_base) $(WK_IOS_PRIVATE_SYMBOLS_DIR)
> +FRAMEWORK_SEARCH_PATHS = $(FRAMEWORK_SEARCH_PATHS_base);

No need to complicate the definition of FRAMEWORK_SEARCH_PATH so much.

First of all, a specialization can refer to the non-specialized value from the same level using $(inherited), so you could have just kept the existing definition of FRAMEWORK_SEARCH_PATH and added below it
FRAMEWORK_SEARCH_PATHS[sdk=iphone*] = $(inherited) $(WK_IOS_PRIVATE_SYMBOLS_DIR);

Furthermore, since WK_IOS_PRIVATE_SYMBOLS_DIR is empty when not targeting iOS, you could have just changed the definition of FRAMEWORK_SEARCH_PATHS to
FRAMEWORK_SEARCH_PATHS = $(WK_QUOTED_OVERRIDE_FRAMEWORKS_DIR) $(WK_IOS_PRIVATE_SYMBOLS_DIR);

This perhaps looks strange (referring to an iOS-specific build setting in a common build setting), but that can be fixed by choosing a better name for WK_IOS_PRIVATE_SYMBOLS_DIR, such as WK_PRIVATE_FRAMEWORK_STUBS_DIR (which I would do anyway).

> WebKitLibraries/ChangeLog:24
> +        * ios/ios-10-private-symbols/AppSupport.framework/AppSupport.tbd: Added.
> +        * ios/ios-10-private-symbols/AssertionServices.framework/AssertionServices.tbd: Added.
> +        * ios/ios-10-private-symbols/CorePDF.framework/CorePDF.tbd: Added.
> +        * ios/ios-10-private-symbols/GraphicsServices.framework/GraphicsServices.tbd: Added.
> +        * ios/ios-10-private-symbols/IOSurface.framework/IOSurface.tbd: Added.
> +        * ios/ios-9-private-symbols/AppSupport.framework/AppSupport.tbd: Added.
> +        * ios/ios-9-private-symbols/AssertionServices.framework/AssertionServices.tbd: Added.
> +        * ios/ios-9-private-symbols/CorePDF.framework/CorePDF.tbd: Added.
> +        * ios/ios-9-private-symbols/GraphicsServices.framework/GraphicsServices.tbd: Added.
> +        * ios/ios-9-private-symbols/IOSurface.framework/IOSurface.tbd: Added.

I don’t like these directory names. I also think we shouldn’t be creating a directory called ios-…-private-symbols at the top level of the built products directory, since people may be sharing a built products directory with other non-WebKit-related projects. So in the built products directory, I’d prefer an organization like this:

$(BUILT_PRODUCTS_DIR)/WebKitPrivateFrameworkStubs/iOS/9
$(BUILT_PRODUCTS_DIR)/WebKitPrivateFrameworkStubs/iOS/10

Which leads me to think that under WebKitLibraries, the organization should be:

WebKitLibraries/WebKitPrivateFrameworkStubs/iOS/9
WebKitLibraries/WebKitPrivateFrameworkStubs/iOS/10

On second thought, I am not convinced that copying the files into the built products directory is even necessary or desirable. We do this static libraries because we process them (though we probably no longer have to) and because it streamlines the configuration by making it similar to the Apple-internal configuration where those libraries are built from source. But with the private framework stubs, could we just leave them in place and add their SRCROOT-relative location to the framework search paths? It would greatly simplify this patch.

[Daniel Bates]

Comment on attachment 285992 [details]
Patch

Will update patch to avoid copying stub files to the built products directory.

[Daniel Bates]

Created attachment 286045 [details]
Patch

[Daniel Bates]

Created attachment 286060 [details]
Patch

[Daniel Bates]

It looks like we can take advantage of the presence of the Xcode build setting TAPI_VERIFY_MODE to determine if Xcode supports text-based stubs.

[Daniel Bates]

Created attachment 286061 [details]
Patch

[Daniel Bates]

Committed r204471: <http://trac.webkit.org/changeset/204471>