The SPI CTFontCreatePhysicalFontForCharactersWithLanguage(), used in the patch for bug #173300, was removed from the macOS 10.13 and iOS 11 SDKs. When targeting macOS 10.12/iOS 10 we should not compile code that invokes CTFontCreatePhysicalFontForCharactersWithLanguage(). Otherwise, WebCore will fail to link as the symbol for CTFontCreatePhysicalFontForCharactersWithLanguage() does not exist in binaries included in the macOS 10.13 and iOS 11 SDKs.
Created attachment 314057 [details] Patch
Comment on attachment 314057 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=314057&action=review It’s incorrect to have the code call a different function at runtime depending on what SDK was used at build time. A correct fix for this bug would be to provide a declaration of the 10.12-era SPI, properly annotated for availability, when using the 10.13-era or later SDKs. > Source/WebCore/platform/graphics/cocoa/FontCacheCoreText.cpp:1263 > +#if !USE_PLATFORM_SYSTEM_FALLBACK_LIST && ((PLATFORM(MAC) && __MAC_OS_X_VERSION_MAX_ALLOWED <= 101200) || (PLATFORM(IOS) && __IPHONE_OS_VERSION_MAX_ALLOWED <= 100000)) <= doesn’t make sense. Did you mean < 101300 and < 110000, respectively? > Source/WebCore/platform/spi/cocoa/CoreTextSPI.h:132 > +#if (PLATFORM(MAC) && __MAC_OS_X_VERSION_MAX_ALLOWED <= 101200) || (PLATFORM(IOS) && __IPHONE_OS_VERSION_MAX_ALLOWED <= 100000) Ditto.
(In reply to mitz from comment #2) > A correct fix for this bug would be to provide a declaration of the > 10.12-era SPI, properly annotated for availability, when using the 10.13-era > or later SDKs. There are examples of this in AVKitSPI.h.
Comment on attachment 314057 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=314057&action=review >> Source/WebCore/platform/graphics/cocoa/FontCacheCoreText.cpp:1263 >> +#if !USE_PLATFORM_SYSTEM_FALLBACK_LIST && ((PLATFORM(MAC) && __MAC_OS_X_VERSION_MAX_ALLOWED <= 101200) || (PLATFORM(IOS) && __IPHONE_OS_VERSION_MAX_ALLOWED <= 100000)) > > <= doesn’t make sense. Did you mean < 101300 and < 110000, respectively? Yes. >> Source/WebCore/platform/spi/cocoa/CoreTextSPI.h:132 >> +#if (PLATFORM(MAC) && __MAC_OS_X_VERSION_MAX_ALLOWED <= 101200) || (PLATFORM(IOS) && __IPHONE_OS_VERSION_MAX_ALLOWED <= 100000) > > Ditto. Yes, I meant < 101300 and < 11000,
Created attachment 314064 [details] Patch
Attachment 314064 [details] did not pass style-queue: ERROR: Source/WebCore/platform/spi/cocoa/CoreTextSPI.h:134: Missing spaces around = [whitespace/operators] [4] ERROR: Source/WebCore/platform/spi/cocoa/CoreTextSPI.h:134: Missing space after , [whitespace/comma] [3] Total errors found: 2 in 3 files If any of these errors are false positives, please file a bug against check-webkit-style.
We can also ask CoreText to put the symbol back.
Comment on attachment 314064 [details] Patch I think the CoreTextSPI.h side of this patch is all that’s needed.
(In reply to mitz from comment #8) > Comment on attachment 314064 [details] > Patch > > I think the CoreTextSPI.h side of this patch is all that’s needed. With only the CoreTextSPI.h change I get the following linker error: [[ Undefined symbols for architecture x86_64: "_CTFontCreatePhysicalFontForCharactersWithLanguage", referenced from: WebCore::lookupFallbackFont(__CTFont const*, WebCore::FontSelectionValue, WTF::AtomicString const&, unsigned short const*, unsigned int) in FontCacheCoreText.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) ]]
We likely need to take the approach as in Listing 3-3 in SDK Compatibility Guide: <https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/cross_development/Using/using.html#//apple_ref/doc/uid/20002000-SW1>.
Created attachment 314072 [details] Patch
Attachment 314072 [details] did not pass style-queue: ERROR: Source/WebCore/platform/spi/cocoa/CoreTextSPI.h:132: Missing spaces around = [whitespace/operators] [4] ERROR: Source/WebCore/platform/spi/cocoa/CoreTextSPI.h:132: Missing space after , [whitespace/comma] [3] Total errors found: 2 in 3 files If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 314072 [details] Patch Attachment 314072 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/4016741 New failing tests: js/intl-datetimeformat.html js/kde/parse.html imported/w3c/web-platform-tests/html/semantics/embedded-content/the-img-element/srcset/parse-a-srcset-attribute.html fast/url/idna2003.html editing/text-iterator/rtl-first-letter-text-iterator-crash.html fast/text/crash-obscure-text.html
Created attachment 314079 [details] Archive of layout-test-results from ews114 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews114 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Comment on attachment 314072 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=314072&action=review > Source/WebCore/platform/graphics/cocoa/FontCacheCoreText.cpp:1260 > +#if !USE_PLATFORM_SYSTEM_FALLBACK_LIST && ((PLATFORM(MAC) && __MAC_OS_X_VERSION_MAX_ALLOWED < 101300) || (PLATFORM(IOS) && __IPHONE_OS_VERSION_MIN_REQUIRED < 110000)) As a rule, we shouldn’t be using different functions at runtime based on what SDK was used at build time. > Source/WebCore/platform/graphics/cocoa/FontCacheCoreText.cpp:1261 > + if (&CTFontCreatePhysicalFontForCharactersWithLanguage != nullptr) I’m not sure what this is supposed to do or under what circumstances this code would build successfully, then load successfully at runtime, but still need to do this check, but if there are such circumstances, then this is not a valid way to null-check a function pointer. See <wtf/darwin/WeakLinking.h>.
Comment on attachment 314072 [details] Patch Attachment 314072 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/4017283 New failing tests: imported/w3c/web-platform-tests/html/dom/reflection-grouping.html js/intl-datetimeformat.html js/kde/parse.html imported/w3c/web-platform-tests/html/dom/reflection-obsolete.html imported/w3c/web-platform-tests/html/semantics/embedded-content/the-img-element/srcset/parse-a-srcset-attribute.html imported/w3c/web-platform-tests/html/dom/reflection-tabular.html fast/url/idna2003.html imported/w3c/web-platform-tests/html/dom/reflection-embedded.html editing/text-iterator/rtl-first-letter-text-iterator-crash.html fast/text/crash-obscure-text.html imported/w3c/web-platform-tests/html/dom/reflection-forms.html
Created attachment 314097 [details] Archive of layout-test-results from ews102 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews102 Port: mac-elcapitan Platform: Mac OS X 10.11.6
(In reply to mitz from comment #15) > Comment on attachment 314072 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=314072&action=review > > > Source/WebCore/platform/graphics/cocoa/FontCacheCoreText.cpp:1260 > > +#if !USE_PLATFORM_SYSTEM_FALLBACK_LIST && ((PLATFORM(MAC) && __MAC_OS_X_VERSION_MAX_ALLOWED < 101300) || (PLATFORM(IOS) && __IPHONE_OS_VERSION_MIN_REQUIRED < 110000)) > > As a rule, we shouldn’t be using different functions at runtime based on > what SDK was used at build time. > How do you propose we fix this bug given comment #9? > > Source/WebCore/platform/graphics/cocoa/FontCacheCoreText.cpp:1261 > > + if (&CTFontCreatePhysicalFontForCharactersWithLanguage != nullptr) > > I’m not sure what this is supposed to do or under what circumstances this > code would build successfully, then load successfully at runtime, but still > need to do this check, but if there are such circumstances, then this is not > a valid way to null-check a function pointer. See <wtf/darwin/WeakLinking.h>. I was just mimicking the approach of Listing 3-3 in SDK Compatibility Guide: <https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/cross_development/Using/using.html#//apple_ref/doc/uid/20002000-SW1> as well as respecting the note about explicit comparison to nullptr in section "Using Weakly Linked Methods, Functions, and Symbols" in the same guide <https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/cross_development/Using/using.html#//apple_ref/doc/uid/20002000-SW4>. I take it that the advice in this guide is not applicable or out-of-date?
(In reply to Daniel Bates from comment #18) > (In reply to mitz from comment #15) > > Comment on attachment 314072 [details] > > Patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=314072&action=review > > > > > Source/WebCore/platform/graphics/cocoa/FontCacheCoreText.cpp:1260 > > > +#if !USE_PLATFORM_SYSTEM_FALLBACK_LIST && ((PLATFORM(MAC) && __MAC_OS_X_VERSION_MAX_ALLOWED < 101300) || (PLATFORM(IOS) && __IPHONE_OS_VERSION_MIN_REQUIRED < 110000)) > > > > As a rule, we shouldn’t be using different functions at runtime based on > > what SDK was used at build time. > > > > How do you propose we fix this bug given comment #9? I don’t have a proposal yet. > > > Source/WebCore/platform/graphics/cocoa/FontCacheCoreText.cpp:1261 > > > + if (&CTFontCreatePhysicalFontForCharactersWithLanguage != nullptr) > > > > I’m not sure what this is supposed to do or under what circumstances this > > code would build successfully, then load successfully at runtime, but still > > need to do this check, but if there are such circumstances, then this is not > > a valid way to null-check a function pointer. See <wtf/darwin/WeakLinking.h>. > > I was just mimicking the approach of Listing 3-3 in SDK Compatibility Guide: > <https://developer.apple.com/library/content/documentation/DeveloperTools/ > Conceptual/cross_development/Using/using.html#//apple_ref/doc/uid/20002000- > SW1> as well as respecting the note about explicit comparison to nullptr in > section "Using Weakly Linked Methods, Functions, and Symbols" in the same > guide > <https://developer.apple.com/library/content/documentation/DeveloperTools/ > Conceptual/cross_development/Using/using.html#//apple_ref/doc/uid/20002000- > SW4>. I take it that the advice in this guide is not applicable or > out-of-date? Correct, the advice may have been applicable to the developer tools available at the time the guide was published, but it is not applicable to the compilers that are currently in use.
(In reply to mitz from comment #19) > (In reply to Daniel Bates from comment #18) > > (In reply to mitz from comment #15) > > > Comment on attachment 314072 [details] > > > Patch > > > > > > View in context: > > > https://bugs.webkit.org/attachment.cgi?id=314072&action=review > > > > > > > Source/WebCore/platform/graphics/cocoa/FontCacheCoreText.cpp:1260 > > > > +#if !USE_PLATFORM_SYSTEM_FALLBACK_LIST && ((PLATFORM(MAC) && __MAC_OS_X_VERSION_MAX_ALLOWED < 101300) || (PLATFORM(IOS) && __IPHONE_OS_VERSION_MIN_REQUIRED < 110000)) > > > > > > As a rule, we shouldn’t be using different functions at runtime based on > > > what SDK was used at build time. > > > > > > > How do you propose we fix this bug given comment #9? > > I don’t have a proposal yet. One option is, iff building for macOS 10.12 with the macOS 10.13 SDK (when building WebKit for iOS, we don’t support targeting an older version than the SDK), to add -Wl,-U,_CTFontCreatePhysicalFontForCharactersWithLanguage to WebCore’s OTHER_LDFLAGS. I think that this is acceptable, because trunk WebCore builds targeting macOS 10.12 are not meant to be included in the dyld shared cache. I believe that another option involves creating and using a .tbd file for Core Text that exports the missing symbols and reexports the real Core Text from the SDK. I’ve experimented with this technique in the past, but haven’t tried to apply it to this case.
(In reply to Myles C. Maxfield from comment #7) > We can also ask CoreText to put the symbol back. I did not mean to ignore your comment. Your "SPIs are forever" (*) ;) solution would fix this bug. I do not know if such a request would be entertained (we could try) or set a good precedent. (*) Does not need to be forever. At least one release.
Or we could soft link. Whichever option you two come up with is fine with me.
(In reply to mitz from comment #20) > (In reply to mitz from comment #19) > > (In reply to Daniel Bates from comment #18) > > > (In reply to mitz from comment #15) > > > > Comment on attachment 314072 [details] > > > > Patch > > > > > > > > View in context: > > > > https://bugs.webkit.org/attachment.cgi?id=314072&action=review > > > > > > > > > Source/WebCore/platform/graphics/cocoa/FontCacheCoreText.cpp:1260 > > > > > +#if !USE_PLATFORM_SYSTEM_FALLBACK_LIST && ((PLATFORM(MAC) && __MAC_OS_X_VERSION_MAX_ALLOWED < 101300) || (PLATFORM(IOS) && __IPHONE_OS_VERSION_MIN_REQUIRED < 110000)) > > > > > > > > As a rule, we shouldn’t be using different functions at runtime based on > > > > what SDK was used at build time. > > > > > > > > > > How do you propose we fix this bug given comment #9? > > > > I don’t have a proposal yet. > > One option is, iff building for macOS 10.12 with the macOS 10.13 SDK (when > building WebKit for iOS, we don’t support targeting an older version than > the SDK), to add -Wl,-U,_CTFontCreatePhysicalFontForCharactersWithLanguage > to WebCore’s OTHER_LDFLAGS. I think that this is acceptable, because trunk > WebCore builds targeting macOS 10.12 are not meant to be included in the > dyld shared cache. > Can you please elaborate on your last sentence. Does your last sentence imply that if we add to OTHER_LDFLAGS we will not crash with a dyld error when trying to invoke CTFontCreatePhysicalFontForCharactersWithLanguage() on macOS 10.13 using a WebCore built targeting macOS 10.12? > I believe that another option involves creating and using a .tbd file for > Core Text that exports the missing symbols and reexports the real Core Text > from the SDK. I’ve experimented with this technique in the past, but haven’t > tried to apply it to this case. Would this technique prevent the crash mentioned above?
(In reply to Daniel Bates from comment #23) > Can you please elaborate on your last sentence. Does your last sentence > imply that if we add to OTHER_LDFLAGS we will not crash with a dyld error > when trying to invoke CTFontCreatePhysicalFontForCharactersWithLanguage() on > macOS 10.13 using a WebCore built targeting macOS 10.12? No. Using a WebKit build targeting one macOS version on a different macOS version is not supported. > > I believe that another option involves creating and using a .tbd file for > > Core Text that exports the missing symbols and reexports the real Core Text > > from the SDK. I’ve experimented with this technique in the past, but haven’t > > tried to apply it to this case. > > Would this technique prevent the crash mentioned above? No.
Another option is we could ask CoreText to put a #define in their headers which represents the presence of this symbol. Then we could test for it.
Created attachment 314618 [details] Patch Use soft-link approach suggested by Myles Maxfield.
(In reply to Daniel Bates from comment #26) > Created attachment 314618 [details] > Patch > > Use soft-link approach suggested by Myles Maxfield. What’s the advantage of this approach over letting the linker resolve this without writing additional code?
Attachment 314618 [details] did not pass style-queue: ERROR: Source/WebCore/platform/spi/cocoa/CoreTextSPI.h:132: Missing spaces around = [whitespace/operators] [4] ERROR: Source/WebCore/platform/spi/cocoa/CoreTextSPI.h:132: Missing space after , [whitespace/comma] [3] Total errors found: 2 in 3 files If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 314618 [details] Patch Attachment 314618 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/4057684 New failing tests: js/intl-datetimeformat.html js/kde/parse.html imported/w3c/web-platform-tests/html/semantics/embedded-content/the-img-element/srcset/parse-a-srcset-attribute.html fast/url/idna2003.html editing/text-iterator/rtl-first-letter-text-iterator-crash.html fast/text/crash-obscure-text.html
Created attachment 314637 [details] Archive of layout-test-results from ews115 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews115 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Comment on attachment 314618 [details] Patch Attachment 314618 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/4058190 New failing tests: imported/w3c/web-platform-tests/html/dom/reflection-grouping.html js/intl-datetimeformat.html js/kde/parse.html imported/w3c/web-platform-tests/html/dom/reflection-obsolete.html imported/w3c/web-platform-tests/html/semantics/embedded-content/the-img-element/srcset/parse-a-srcset-attribute.html imported/w3c/web-platform-tests/html/dom/reflection-tabular.html fast/url/idna2003.html imported/w3c/web-platform-tests/html/dom/reflection-embedded.html editing/text-iterator/rtl-first-letter-text-iterator-crash.html fast/text/crash-obscure-text.html imported/w3c/web-platform-tests/html/dom/reflection-forms.html
Created attachment 314649 [details] Archive of layout-test-results from ews101 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews101 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Created attachment 314671 [details] Patch
Created attachment 314693 [details] Patch
Comment on attachment 314693 [details] Patch What’s the advantage of this approach over letting the linker resolve this without writing additional code?
Created attachment 314888 [details] Patch
Attachment 314888 [details] did not pass style-queue: ERROR: Source/WebCore/platform/spi/cocoa/CoreTextSPI.h:133: Missing spaces around = [whitespace/operators] [4] ERROR: Source/WebCore/platform/spi/cocoa/CoreTextSPI.h:133: Missing space after , [whitespace/comma] [3] Total errors found: 2 in 3 files If any of these errors are false positives, please file a bug against check-webkit-style.
I'll let Mitz review this.
Created attachment 314896 [details] Patch
Attachment 314896 [details] did not pass style-queue: ERROR: Source/WebCore/platform/spi/cocoa/CoreTextSPI.h:133: Missing spaces around = [whitespace/operators] [4] ERROR: Source/WebCore/platform/spi/cocoa/CoreTextSPI.h:133: Missing space after , [whitespace/comma] [3] Total errors found: 2 in 3 files If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 314896 [details] Patch Clearing flags on attachment: 314896 Committed r219294: <http://trac.webkit.org/changeset/219294>
All reviewed patches have been landed. Closing bug.
Ld /Users/ysuzuki/neko/WebKitBuild/Release/WebCore.framework/Versions/A/WebCore normal x86_64 cd /Users/ysuzuki/neko/Source/WebCore export MACOSX_DEPLOYMENT_TARGET=10.12 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -arch x86_64 -dynamiclib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -L/Users/ysuzuki/neko/WebKitBuild/Release -L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebCore.framework/Versions/A/Frameworks -F/Users/ysuzuki/neko/WebKitBuild/Release -F/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/PrivateFrameworks -filelist /Users/ysuzuki/neko/WebKitBuild/WebCore.build/Release/WebCore.build/Objects-normal/x86_64/WebCore.LinkFileList -unexported_symbols_list Configurations/WebCore.unexp -install_name /System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebCore.framework/Versions/A/WebCore -mmacosx-version-min=10.12 -dead_strip -Xlinker -object_path_lto -Xlinker /Users/ysuzuki/neko/WebKitBuild/WebCore.build/Release/WebCore.build/Objects-normal/x86_64/WebCore_lto.o -stdlib=libc++ -fobjc-link-runtime -Wl,-not_for_dyld_shared_cache -lsqlite3 -lobjc -lANGLE -framework CoreAudio -framework Metal -allowable_client WebCoreTestSupport -allowable_client WebKitLegacy -force_load /Users/ysuzuki/neko/WebKitBuild/Release/libPAL.a -sub_library libobjc -umbrella WebKit -framework ApplicationServices -framework AudioUnit -framework Carbon -framework Cocoa -framework DataDetectorsCore -framework IOSurface -framework OpenGL -framework SystemConfiguration -framework VideoToolbox -framework CoreMedia -weak-lwebrtc -framework Accelerate -framework AudioToolbox -framework IOKit -framework JavaScriptCore -licucore -lobjc /Users/ysuzuki/neko/WebKitBuild/Release/libPAL.a -lxml2 -lz -framework QuartzCore -framework Security -single_module -compatibility_version 1 -current_version 605.1.17 -Xlinker -dependency_info -Xlinker /Users/ysuzuki/neko/WebKitBuild/WebCore.build/Release/WebCore.build/Objects-normal/x86_64/WebCore_dependency_info.dat -o /Users/ysuzuki/neko/WebKitBuild/Release/WebCore.framework/Versions/A/WebCore Undefined symbols for architecture x86_64: "_CTFontCreatePhysicalFontForCharactersWithLanguage", referenced from: WebCore::FontCache::systemFallbackForCharacters(WebCore::FontDescription const&, WebCore::Font const*, bool, unsigned short const*, unsigned int) in UnifiedSource354.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) ** BUILD FAILED **
It seems broken again on Sierra.
(In reply to Basuke Suzuki from comment #43) > Ld > /Users/ysuzuki/neko/WebKitBuild/Release/WebCore.framework/Versions/A/WebCore > normal x86_64 > cd /Users/ysuzuki/neko/Source/WebCore > export MACOSX_DEPLOYMENT_TARGET=10.12 > > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault. > xctoolchain/usr/bin/clang++ -arch x86_64 -dynamiclib -isysroot > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/ > Developer/SDKs/MacOSX10.13.sdk -L/Users/ysuzuki/neko/WebKitBuild/Release > -L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/ > Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/WebKit.framework/ > Versions/A/Frameworks/WebCore.framework/Versions/A/Frameworks > -F/Users/ysuzuki/neko/WebKitBuild/Release > -F/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/ > Developer/SDKs/MacOSX10.13.sdk/System/Library/PrivateFrameworks -filelist > /Users/ysuzuki/neko/WebKitBuild/WebCore.build/Release/WebCore.build/Objects- > normal/x86_64/WebCore.LinkFileList -unexported_symbols_list > Configurations/WebCore.unexp -install_name > /System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebCore. > framework/Versions/A/WebCore -mmacosx-version-min=10.12 -dead_strip -Xlinker > -object_path_lto -Xlinker > /Users/ysuzuki/neko/WebKitBuild/WebCore.build/Release/WebCore.build/Objects- > normal/x86_64/WebCore_lto.o -stdlib=libc++ -fobjc-link-runtime > -Wl,-not_for_dyld_shared_cache -lsqlite3 -lobjc -lANGLE -framework CoreAudio > -framework Metal -allowable_client WebCoreTestSupport -allowable_client > WebKitLegacy -force_load /Users/ysuzuki/neko/WebKitBuild/Release/libPAL.a > -sub_library libobjc -umbrella WebKit -framework ApplicationServices > -framework AudioUnit -framework Carbon -framework Cocoa -framework > DataDetectorsCore -framework IOSurface -framework OpenGL -framework > SystemConfiguration -framework VideoToolbox -framework CoreMedia > -weak-lwebrtc -framework Accelerate -framework AudioToolbox -framework IOKit > -framework JavaScriptCore -licucore -lobjc > /Users/ysuzuki/neko/WebKitBuild/Release/libPAL.a -lxml2 -lz -framework > QuartzCore -framework Security -single_module -compatibility_version 1 > -current_version 605.1.17 -Xlinker -dependency_info -Xlinker > /Users/ysuzuki/neko/WebKitBuild/WebCore.build/Release/WebCore.build/Objects- > normal/x86_64/WebCore_dependency_info.dat -o > /Users/ysuzuki/neko/WebKitBuild/Release/WebCore.framework/Versions/A/WebCore > Undefined symbols for architecture x86_64: > "_CTFontCreatePhysicalFontForCharactersWithLanguage", referenced from: > > WebCore::FontCache::systemFallbackForCharacters(WebCore::FontDescription > const&, WebCore::Font const*, bool, unsigned short const*, unsigned int) in > UnifiedSource354.o > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > ** BUILD FAILED ** (In reply to Basuke Suzuki from comment #44) > It seems broken again on Sierra. This build failure was caused by changeset r225179, <https://trac.webkit.org/changeset/225179/> (bug #180011). Committed fix in <https://trac.webkit.org/changeset/225757/>.
<rdar://problem/35979297>
Broken yet again on Sierra? Ld /Users/RKirsling/Documents/GitHub/neko/WebKitBuild/Release/WebCore.framework/Versions/A/WebCore normal x86_64 cd /Users/RKirsling/Documents/GitHub/neko/Source/WebCore export MACOSX_DEPLOYMENT_TARGET=10.12 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -arch x86_64 -dynamiclib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -L/Users/RKirsling/Documents/GitHub/neko/WebKitBuild/Release -L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebCore.framework/Versions/A/Frameworks -F/Users/RKirsling/Documents/GitHub/neko/WebKitBuild/Release -F/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/PrivateFrameworks -filelist /Users/RKirsling/Documents/GitHub/neko/WebKitBuild/WebCore.build/Release/WebCore.build/Objects-normal/x86_64/WebCore.LinkFileList -unexported_symbols_list Configurations/WebCore.unexp -install_name /System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebCore.framework/Versions/A/WebCore -mmacosx-version-min=10.12 -dead_strip -Xlinker -object_path_lto -Xlinker /Users/RKirsling/Documents/GitHub/neko/WebKitBuild/WebCore.build/Release/WebCore.build/Objects-normal/x86_64/WebCore_lto.o -stdlib=libc++ -fobjc-link-runtime -Wl,-not_for_dyld_shared_cache -lsqlite3 -lobjc -lANGLE -framework CoreAudio -framework Metal -allowable_client WebCoreTestSupport -allowable_client WebKitLegacy -force_load /Users/RKirsling/Documents/GitHub/neko/WebKitBuild/Release/libPAL.a -sub_library libobjc -umbrella WebKit -framework ApplicationServices -framework AudioUnit -framework Carbon -framework Cocoa -framework DataDetectorsCore -framework IOSurface -framework OpenGL -framework SystemConfiguration -framework VideoToolbox -framework CoreMedia -weak-lwebrtc -framework Accelerate -framework AudioToolbox -framework IOKit -framework JavaScriptCore -licucore -lobjc /Users/RKirsling/Documents/GitHub/neko/WebKitBuild/Release/libPAL.a -lxml2 -lz -framework QuartzCore -framework Security -single_module -compatibility_version 1 -current_version 606.1.3 -Xlinker -dependency_info -Xlinker /Users/RKirsling/Documents/GitHub/neko/WebKitBuild/WebCore.build/Release/WebCore.build/Objects-normal/x86_64/WebCore_dependency_info.dat -o /Users/RKirsling/Documents/GitHub/neko/WebKitBuild/Release/WebCore.framework/Versions/A/WebCore Undefined symbols for architecture x86_64: "_CTFontCreatePhysicalFontForCharactersWithLanguage", referenced from: WebCore::FontCache::systemFallbackForCharacters(WebCore::FontDescription const&, WebCore::Font const*, bool, unsigned short const*, unsigned int) in UnifiedSource361.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)
(In reply to Ross Kirsling from comment #47) > Broken yet again on Sierra? Sorry, looks like <https://trac.webkit.org/r227156> broke it. It should be easy to fix.
Should be fix with <https://trac.webkit.org/r227376>.
Do we even still care to support cross-compiling in this manner? Is there a need?
The intention isn't to cross-compile but simply to have the build succeed on Sierra. Unfortunately, our IT department continues to disallow upgrading to High Sierra for the time being.
Indeed, it's valid to expect that WebKit builds with the latest shipping Xcode, so I guess we need to keep caring. But practically speaking, it may be easiest to downgrade to Xcode 8, as that includes a matching SDK for macOS Sierra.