[Webkit-unassigned] [Bug 153176] [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)

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=153176

Michael Catanzaro <mcatanzaro at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |achristensen at apple.com

--- Comment #10 from Michael Catanzaro <mcatanzaro at igalia.com> ---
(In reply to comment #9)
> 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?

Clearly we need to figure out what's up here. The static libraries are "convenience libs" which are never installed: they're only there to make reasoning about the build system easier, and so that we can catch layering violations between the libraries. MiniBrowser should only be linking to libwebkit2gtk-4.0.37.13.0.dylib and libjavascriptcoregtk-4.0.18.3.2.dylib.

I wonder if the Mac port is having any similar linking problems?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160117/982bdebf/attachment.html>