Bug 173939 – REGRESSION (r218616, r225179): Cannot build WebCore for macOS 10.12 with macOS 10.13 SDK (missing _CTFontCreatePhysicalFontForCharactersWithLanguage)

• Component: WebCore Misc.
• Status: RESOLVED FIXED

[Daniel Bates]

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.

[Daniel Bates]

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.

[Daniel Bates]

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,

[Daniel Bates]

Created attachment 314064 [details]
Patch

[Build Bot]

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.

[Myles C. Maxfield]

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.

[Daniel Bates]

(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)
]]

[Daniel Bates]

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>.

[Daniel Bates]

Created attachment 314072 [details]
Patch

[Build Bot]

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.

[Build Bot]

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

[Build Bot]

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>.

[Build Bot]

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

[Build Bot]

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

[Daniel Bates]

(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.

[Daniel Bates]

(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.

[Myles C. Maxfield]

Or we could soft link.

Whichever option you two come up with is fine with me.

[Daniel Bates]

(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.

[Myles C. Maxfield]

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.

[Daniel Bates]

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?

[Build Bot]

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.

[Build Bot]

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

[Build Bot]

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

[Build Bot]

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

[Build Bot]

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

[Myles C. Maxfield]

Created attachment 314671 [details]
Patch

[Myles C. Maxfield]

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?

[Daniel Bates]

Created attachment 314888 [details]
Patch

[Build Bot]

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.

[Myles C. Maxfield]

I'll let Mitz review this.

[Daniel Bates]

Created attachment 314896 [details]
Patch

[Build Bot]

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.

[Daniel Bates]

Comment on attachment 314896 [details]
Patch

Clearing flags on attachment: 314896

Committed r219294: <http://trac.webkit.org/changeset/219294>

[Daniel Bates]

All reviewed patches have been landed.  Closing bug.

[Basuke Suzuki]

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 **

[Basuke Suzuki]

It seems broken again on Sierra.

[Daniel Bates]

(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/>.

[Radar WebKit Bug Importer]

<rdar://problem/35979297>

[Ross Kirsling]

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>.

[Alexey Proskuryakov]

Do we even still care to support cross-compiling in this manner? Is there a need?

[Ross Kirsling]

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.

[Alexey Proskuryakov]

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.