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)
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
<rdar://problem/25807989>
Created attachment 285916 [details] Patch
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.
Created attachment 285978 [details] Patch
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.
Comment on attachment 285992 [details] Patch Will update patch to avoid copying stub files to the built products directory.
Created attachment 286045 [details] Patch
Created attachment 286060 [details] Patch
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.
Created attachment 286061 [details] Patch
Committed r204471: <http://trac.webkit.org/changeset/204471>