RESOLVED FIXED 155931
Cannot build WebKit for iOS device using Xcode 7.3/iOS 9.3 public SDK due to missing private frameworks and libraries
https://bugs.webkit.org/show_bug.cgi?id=155931
Summary Cannot build WebKit for iOS device using Xcode 7.3/iOS 9.3 public SDK due to ...
Hofi
Reported 2016-03-27 00:32:20 PDT
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: enrica@apple.com Last Changed Rev: 198684 Last Changed Date: 2016-03-25 20:32:53 +0100 (Fri, 25 Mar 2016)
Attachments
Patch (30.66 KB, patch)
2016-08-12 10:08 PDT, Daniel Bates
no flags
Patch (30.64 KB, patch)
2016-08-12 14:16 PDT, Daniel Bates
no flags
Patch (31.81 KB, patch)
2016-08-12 16:49 PDT, Daniel Bates
no flags
Patch (31.82 KB, patch)
2016-08-12 18:42 PDT, Daniel Bates
no flags
Patch (23.89 KB, patch)
2016-08-14 17:46 PDT, Daniel Bates
no flags
Patch (25.89 KB, patch)
2016-08-15 09:45 PDT, Daniel Bates
no flags
Patch (24.18 KB, patch)
2016-08-15 10:00 PDT, Daniel Bates
mitz: review+
Daniel Bates
Comment 1 2016-04-11 20:43:21 PDT
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
Comment 2 2016-04-19 11:16:05 PDT
Daniel Bates
Comment 3 2016-08-12 10:08:59 PDT
Daniel Bates
Comment 4 2016-08-12 14:16:38 PDT
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
Comment 5 2016-08-12 16:49:18 PDT
Daniel Bates
Comment 6 2016-08-12 18:42:54 PDT
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.
mitz
Comment 7 2016-08-13 13:16:01 PDT
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
mitz
Comment 8 2016-08-13 14:58:06 PDT
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 9 2016-08-13 16:37:28 PDT
Comment on attachment 285992 [details] Patch Will update patch to avoid copying stub files to the built products directory.
Daniel Bates
Comment 10 2016-08-14 17:46:22 PDT
Daniel Bates
Comment 11 2016-08-15 09:45:33 PDT
Daniel Bates
Comment 12 2016-08-15 09:56:10 PDT
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
Comment 13 2016-08-15 10:00:45 PDT
Daniel Bates
Comment 14 2016-08-15 11:58:55 PDT
Note You need to log in before you can comment on or make changes to this bug.