[webkit-gtk] WTF is in both libjavascriptcoregtk and libwebkit2gtk

[Jeremy Huddleston Sequoia]

Unfortunately, it's not just restricted to WTF here.  That's just the most immediately obvious problem.  This seems to be a more systemic problem with the cmake build system as a whole.  I am relatively new to cmake, so I don't quite understand why it's doing what it's doing half the time.  However, it seems that whenever we link a target, we will link in the libraries in the target's _LIBRARIES variable plus any of those libraries' targets' _LIBRARIES (ie, recurse).  That works perfectly if all the libraries are static archives, but it seems that cmake doesn't understand that libwebkit2gtk and libjavascriptcoregtk are shared libraries that already contain that support.

In the case of MiniBrowser, we are linking against:

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 and WebKit2 should just result in linking libwebkit2gtk and libjavascriptcoregtk, not linking those dylibs *AND* all the static archives that went into them.



> On Jan 16, 2016, at 11:33, Jeremy Huddleston Sequoia <jeremyhu at macports.org> wrote:
> 
> 
>> On Jan 16, 2016, at 06:06, Adrián Pérez de Castro <aperez at igalia.com> wrote:
>> 
>> Hello,
>> 
>> Quoting Carlos Garcia Campos (2016-01-16 15:03:39)
>>> El vie, 15-01-2016 a las 22:57 -0800, Jeremy Huddleston Sequoia
>>> escribió:
>>>> Hey folks,
>>>> 
>>>> WebKit2 isn't initializing correctly for us in 2.11.3, and clients
>>>> are crashing on initial launch.
>>>> 
>>>> Philip first mentioned this in https://bugs.webkit.org/show_bug.cgi?i
>>>> d=144557, and the issue is currently being tracked in
>>>> https://bugs.webkit.org/show_bug.cgi?id=153176
>>>> 
>>>> Note that this is a regression since 2.4.x, so it may have been this
>>>> way for quite a while.
>>>> 
>>>> The crux of the issue is that WebKit::InitializeWebKit2() calls
>>>> JSC::initializeThreading() which calls
>>>> WTF::initializeThreading().  However, there are two different copies
>>>> of WTF::initializeThreading() in process.  One
>>>> WTF::initializeThreading() is in libjavascriptcoregtk, and the other
>>>> is in libwebkit2gtk.  The libwebkit2gtk version thus does not get
>>>> initialized, and we fail an assertion in here.
>>>> 
>>>> Obviously, we want just a single instance of this class.
>>>> 
>>>> Should WTF be a separate dylib?  It sounds like that's appropriate
>>>> based on this layering.  Is the WTF API expected to be provided by
>>>> both libjavascriptcoregtk and libwebkit2gtk?
>>> 
>>> I think this is because WebCore and JSC are both linking to WTF
>>> statically. Since WebCore depends on JSC maybe we could just remove WTF
>>> from WebCore CMakeLists. Could you try removing WTF${DEBUG_SUFFIX}
>>> from WebCore_LIBRARIES in Source/WebCore/CMakeLists.txt?
> 
>> That may not work: the linker will only pick from static libraries the *.o
>> objects it needs. That is: only *.o files from which symbols are used will
>> be copied to the output libjavascriptcoregtk.so
> 
> Not the case with -Wl,--whole-archive for GNU's linker and -Wl,-all_load as we're doing with ld64.
> 
> However, it won't work for a different reason.  Removing WTF${DEBUG_SUFFIX} from WebCore_LIBRARIES will cause clients of libwebkit2gtk that depend on the WTF APIs to fail to link unless they add a new link against libjavascriptcoregtk.  Similarly, existing clients of libwebkit2gtk will no longer find their symbols in libwebkit2gtk and will thus fail to load.
> 
>> — if libwebkit2gtk.so uses
>> symbols from WTF which pull additional *.o files from the WTF static library,
>> then the dynamic linker won't be able to load it at run-time.
>> 
>> IMHO a shared libWTF.so may as well be the best solution.
> 
> Yeah, that's where I was leaning.  That should also hopefully allow us to build with debug symbols.  Currently, the addition of debug symbols causes the resulting static archive to be too large, crashing ar. =(
> 
>> 
>> Cheers,
>> 
>> --
>> ⌨ Adrian
>> 
> 
> _______________________________________________
> webkit-gtk mailing list
> webkit-gtk at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-gtk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4118 bytes
Desc: not available
URL: <https://lists.webkit.org/pipermail/webkit-gtk/attachments/20160116/bbb9def6/attachment.p7s>