Bug 214034 - dyld: Symbol not found: __ZN3WTF19initializeThreadingEv - webkit MacOSX
Summary: dyld: Symbol not found: __ZN3WTF19initializeThreadingEv - webkit MacOSX
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Geoffrey Garen
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-07-06 23:49 PDT by Joe
Modified: 2020-07-08 12:32 PDT (History)
10 users (show)

See Also:


Attachments
compilation_log.zip (1.55 MB, application/x-zip-compressed)
2020-07-06 23:49 PDT, Joe
no flags Details
Patch (1.23 KB, patch)
2020-07-08 11:27 PDT, Geoffrey Garen
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Joe 2020-07-06 23:49:19 PDT
Created attachment 403669 [details]
compilation_log.zip

I'm trying to run safari/webkit from custom build, but at the end I get error like in the topic. From the beginning.

My Os : MacOS Catalina ver 10.15.5

Xcode : 11.5

Webkit source code obtained from git:

git clone git://git.webkit.org/WebKit.git webkit 

next build:

./Tools/Scripts/set-webkit-configuration --asan
./Tools/Scripts/build-webkit
I got info at the end that build succeeded :

** BUILD SUCCEEDED ** [2.393 sec]


====================================================================
 WebKit is now built (1h:03m:30s). 
 To run Safari with this newly-built code, use the
 "Tools/Scripts/run-safari" script.
====================================================================
Trying to run below script I endup with an error:

MagicTerminal:webkit joe$ ./Tools/Scripts/run-safari
Starting SafariForWebKitDevelopment with DYLD_FRAMEWORK_PATH set to point to built WebKit in /Users/joe/projects/webkit/WebKitBuild/Release.
dyld: Symbol not found: __ZN3WTF19initializeThreadingEv
  Referenced from: /System/Library/PrivateFrameworks/Safari.framework/Versions/A/Safari
  Expected in: /Users/joe/projects/webkit/WebKitBuild/Release/JavaScriptCore.framework/Versions/A/JavaScriptCore
 in /System/Library/PrivateFrameworks/Safari.framework/Versions/A/Safari

Any idea how to solve that problem ?
I'm attaching a log from a compilation process.
Comment 1 Alexey Proskuryakov 2020-07-07 18:29:34 PDT
Did this work for you before http://trac.webkit.org/r263635 ? That change had the function renamed, and obviously broke running against shipping Safari, but we weren't sure if it was already broken for other reasons.
Comment 2 Joe 2020-07-08 00:39:16 PDT
Nice! I revert to e1cb69a commit and that solved me problem. So indeed it seems that changes pointed by you are causing mentioned by me issue.
Are you guys planning to solve it somehow ?

Thanks ;)
Comment 3 Geoffrey Garen 2020-07-08 11:10:17 PDT
Yes, we can solve this.
Comment 4 Geoffrey Garen 2020-07-08 11:27:11 PDT
Created attachment 403797 [details]
Patch
Comment 5 Mark Lam 2020-07-08 11:28:07 PDT
Comment on attachment 403797 [details]
Patch

r=me
Comment 6 EWS 2020-07-08 12:29:33 PDT
Committed r264126: <https://trac.webkit.org/changeset/264126>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 403797 [details].
Comment 7 Radar WebKit Bug Importer 2020-07-08 12:30:17 PDT
<rdar://problem/65236008>
Comment 8 Darin Adler 2020-07-08 12:32:25 PDT
Comment on attachment 403797 [details]
Patch

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

> Source/WTF/wtf/Threading.cpp:379
> +// This is a compatibility hack to prevent linkage errors when launching older
> +// versions of Safari. initialize() used to be named initializeThreading(), and
> +// Safari.framework used to call it directly from NotificationAgentMain.
> +WTF_EXPORT_PRIVATE void initializeThreading();
> +void initializeThreading()
> +{
> +    initialize();
> +}

Would be nice if we left a slightly more explicit crumb around for *when* we can remove this. I think we used to have a header with these "needed only for old Safari linking" in it, which helped group them for simultaneous removal. Often they were empty functions. Nothing makes me want this function to be in this source file, since the consideration is not about our threading design.