[AppleWin] The procedure entry point ?waitForThreadCompletion@WTF@@YAHI@Z could not be located in the dynamic link library WebKitQuartzCoreAdditions.dll AppleWin port debug build trunk@215506 While starting MiniBrowser, a message box is shown. > The procedure entry point ?waitForThreadCompletion@WTF@@YAHI@Z could not be located in the dynamic link library C:\Program Files (x86)\Common Files\Apple\Apple Application Support\WebKitQuartzCoreAdditions.dll Pushing its OK button, MiniBrowser seems working fine. waitForThreadCompletion was removed in Bug 170502.
Is Bug 25348 Comment 22 a similar issue?
Alex, can we update WebKitQuartzCoreAdditions.dll thing? Or should we leave the binary compatible layer over the new threading mechanism? It is ok to add such a layere if it is necessary.
Not sure. Brent has updated those libraries before. I haven't. We could add a stub waitForThreadCompletion for binary compatibility if it's no problem.
Created attachment 307960 [details] dumpbin /imports WebKitQuartzCoreAdditions.dll Here are the symbols imported from WTF.dll.
(In reply to Fujii Hironori from comment #4) > Created attachment 307960 [details] > dumpbin /imports WebKitQuartzCoreAdditions.dll > > Here are the symbols imported from WTF.dll. OK, let's create a workaround for Windows. It seems that we need to have + waitForThreadCompletion + createThread Ideally, in the next update, these things should be removed.
Created attachment 307962 [details] Patch
Yes -- I'll try to get this fixed ASAP. The WebKitQuartzCoreAdditions relies on WTF for some of its threading functions, and after the API was changed they are no longer compatible.
Comment on attachment 307962 [details] Patch Please, no! Let's just fix the problem.
<rdar://problem/31789014>
Comment on attachment 307962 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=307962&action=review > Source/WTF/ChangeLog:9 > + waitForThreadCompletion and createThread. This patch implements the both on the top of the new APIs. This patch implements BOTH ON TOP of the new APIs. > Source/WTF/wtf/ThreadHolder.cpp:-53 > - threadSpecificSet(m_key, new ThreadHolder(thread)); Let's keep this ugly: #if !OS(WINDOWS) threadSpecificSet ... #else // FIXME: Remove this workaround code once <rdar://problem/31793213> is fixed. > Source/WTF/wtf/ThreadHolder.cpp:55 > + platformInitialize(holder); #endif > Source/WTF/wtf/ThreadHolder.h:78 > + static void platformInitialize(ThreadHolder*); I think this should be "#if OS(WINDOWS)", too. > Source/WTF/wtf/ThreadHolderPthreads.cpp:52 > +} Remove this whole thing. > Source/WTF/wtf/ThreadHolderWin.cpp:72 > Add a comment: "// FIXME: Remove this workaround code once <rdar://problem/31793213> is fixed." > Source/WTF/wtf/Threading.h:219 > +// https://bugs.webkit.org/show_bug.cgi?id=171029 Remove this Bugzilla bug, since this is the bug where the workaround was added. Instead, say: "// Remove this workaround code when <rdar://problem/31793213> is fixed." > Source/WTF/wtf/ThreadingWin.cpp:514 > Add a comment: "// FIXME: Remove this workaround code once <rdar://problem/31793213> is fixed."
I looked into it, and I can't fix this as easily as I had hoped, since WebKitQuartzCoreAdditions is installed with Apple Software, not with our own development Zip file. So, we have to keep this backwards-compatibility code until new Apple software rolls out externally. So I'm approving your patch, but would like you to add some comments to remind us to remove this when the relevant code ships.
Comment on attachment 307962 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=307962&action=review OK, thanks! >> Source/WTF/ChangeLog:9 >> + waitForThreadCompletion and createThread. This patch implements the both on the top of the new APIs. > > This patch implements BOTH ON TOP of the new APIs. Fixed. >> Source/WTF/wtf/ThreadHolder.cpp:-53 >> - threadSpecificSet(m_key, new ThreadHolder(thread)); > > Let's keep this ugly: > #if !OS(WINDOWS) > threadSpecificSet ... > #else > // FIXME: Remove this workaround code once <rdar://problem/31793213> is fixed. Fixed. >> Source/WTF/wtf/ThreadHolder.cpp:55 >> + platformInitialize(holder); > > #endif Fixed. >> Source/WTF/wtf/ThreadHolder.h:78 >> + static void platformInitialize(ThreadHolder*); > > I think this should be "#if OS(WINDOWS)", too. Fixed. >> Source/WTF/wtf/ThreadHolderPthreads.cpp:52 >> +} > > Remove this whole thing. OK, dropped. >> Source/WTF/wtf/ThreadHolderWin.cpp:72 >> > > Add a comment: > > "// FIXME: Remove this workaround code once <rdar://problem/31793213> is fixed." Added. >> Source/WTF/wtf/Threading.h:219 >> +// https://bugs.webkit.org/show_bug.cgi?id=171029 > > Remove this Bugzilla bug, since this is the bug where the workaround was added. > > Instead, say: "// Remove this workaround code when <rdar://problem/31793213> is fixed." OK, fixed this part! >> Source/WTF/wtf/ThreadingWin.cpp:514 >> > > Add a comment: > > "// FIXME: Remove this workaround code once <rdar://problem/31793213> is fixed." Added.
Created attachment 308045 [details] Patch
Committed r215713: <http://trac.webkit.org/changeset/215713>
Hi, now, one year later, can we remove this workaround?