[Webkit-unassigned] [Bug 179914] [GTK] Duplicated symbols in libjavascriptcoregtk and libwebkit2gtk can cause crashes in production builds

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Dec 13 15:45:07 PST 2017


--- Comment #57 from Michael Catanzaro <mcatanzaro at igalia.com> ---
I'm going to ask for help in some different places. There are toolchain experts on fedora-devel who might point us at a solution. But I suspect the answer is going to be "you have to export global template instantiations, or not use them." Clearly they cannot be local.

Clearly, using a linker script to mark all symbols as local by default is incompatible with C++ templates (when used as global variables). I think -fvisibility=hidden would have the same problem; there is a note on the GCC man page that that can break exceptions thrown between libraries....

(In reply to Carlos Garcia Campos from comment #56)
> >  but it is present in the system library path, and we really
> > shouldn't be exposing the internals of the library there.
> This is not easy to avoid I'm afraid.

This is probably a fool's errand, but Christian says:

"if you want to share the routines in your statics with two shared libraries you need to one of: 1) add a third support shared library with symbols exported  2) export them from one library  3) link in the routines twice (and therefore larger binary sizes)"

And I believe that is correct. Option (2) is what we do now. Option (3) would entail linking libwk directly to bmalloc and WTF and a second static static build of libjsc, so libjsc and libwk would each have their own copy of that code. A variant on this would be to build libjsc as *static* rather than shared, and use that as we currently do. WebKit links to that. Then we can build a *new* shared libjsc that links to the static libjsc, which just exports the JSC API. (That would be the C API, and, in the future, the GObject API). The cost is we'll then wind up with two copies of bmalloc and WTF, one inside our installed shared libjsc and one inside libwk.

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

More information about the webkit-unassigned mailing list