<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [CMake][GTK][OSX] ThreadIdentifierData::initialize assertion fails because there are two copies of WTF in process (one as part of webkit2, one as part of jsc)"
href="https://bugs.webkit.org/show_bug.cgi?id=153176#c9">Comment # 9</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [CMake][GTK][OSX] ThreadIdentifierData::initialize assertion fails because there are two copies of WTF in process (one as part of webkit2, one as part of jsc)"
href="https://bugs.webkit.org/show_bug.cgi?id=153176">bug 153176</a>
from <span class="vcard"><a class="email" href="mailto:jeremyhu@apple.com" title="Jeremy Huddleston Sequoia <jeremyhu@apple.com>"> <span class="fn">Jeremy Huddleston Sequoia</span></a>
</span></b>
<pre>It looks like this goes well beyond just WTF. Most of the executables are linking against both the dylibs and static archives. For example MiniBrowser is linking
libwebkit2gtk-4.0.37.13.0.dylib
libjavascriptcoregtk-4.0.18.3.2.dylib
libbmalloc.a
libWebCoreGTK.a
libANGLESupport.a
libGObjectDOMBindings.a
libWebCorePlatformGTK.a
libWTFGTK.a
Why does cmake not realize that the functionality provided by those static archives is already rolled into the dylibs that it built? Depending on JavaScriptCore should just result in linking that dylib, not linking that dylib *AND* all the static archives that went into that dylib.
Have I mentioned how much I dislike cmake?</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>