Bug 219457 – [WPE][JSC] Some JSC GLib API symbols are not being exported

• Component: WPE WebKit
• Status: RESOLVED DUPLICATE

[Adrian Perez]

Some JSC API symbols are not being exported, I noticed this because
I am trying to write a program that uses jsc_options_get_option_group()
and the linker cannot find the symbol in libWPEWebKit-1.0.so

This happens at least with versions 2.28.4, 2.30.3, and “trunk”.

(There might be other symbols which are being hidden, I only checked
the one above for now.)

[Adrian Perez]

Okay, I think that the most proper solution for this issue will
be what Don is hacking for bug #210366 but I have a WIP patch which
only does the minimal set up to arrange linker flags to pass the
following when linking the main library when the JavaScriptCore
target is a static library:

  -Wl,--whole-archive path/to/libJavaScriptCore.a -Wl,--no-whole-archive

This results in the following public API symbols being correctly
defined in the resulting libWPEWebKit-1.0.so file:

% diff -u symbols.{before,after}
--- symbols.before      2020-12-07 22:43:25.668206879 +0200
+++ symbols.after       2020-12-08 11:47:42.071833177 +0200
@@ -45,6 +45,25 @@
 jsc_exception_new_with_name_vprintf
 jsc_exception_report
 jsc_exception_to_string
+jsc_get_major_version
+jsc_get_micro_version
+jsc_get_minor_version
+jsc_options_foreach
+jsc_options_get_boolean
+jsc_options_get_double
+jsc_options_get_int
+jsc_options_get_option_group
+jsc_options_get_range_string
+jsc_options_get_size
+jsc_options_get_string
+jsc_options_get_uint
+jsc_options_set_boolean
+jsc_options_set_double
+jsc_options_set_int
+jsc_options_set_range_string
+jsc_options_set_size
+jsc_options_set_string
+jsc_options_set_uint
 jsc_value_constructor_call
 jsc_value_constructor_callv
 jsc_value_function_call
@@ -94,6 +113,9 @@
 jsc_value_to_string_as_bytes
 jsc_virtual_machine_get_type
 jsc_virtual_machine_new
+jsc_weak_value_get_type
+jsc_weak_value_get_value
+jsc_weak_value_new
 webkit_accessible_get_type
 webkit_accessible_hyperlink_get_type
 webkit_application_info_get_name
%

[Adrian Perez]

*** Bug 200033 has been marked as a duplicate of this bug. ***

[Adrian Perez]

(In reply to Adrian Perez from comment #1)
> Okay, I think that the most proper solution for this issue will
> be what Don is hacking for bug #210366 but I have a WIP patch which
> only does the minimal set up to arrange linker flags to pass the
> following when linking the main library when the JavaScriptCore
> target is a static library:
> 
>   -Wl,--whole-archive path/to/libJavaScriptCore.a -Wl,--no-whole-archive

For reference this is the hack that I have applied locally to achieve
this and get the symbols to be in the shared library object:

diff --git a/Source/WebKit/CMakeLists.txt b/Source/WebKit/CMakeLists.txt
index be0865132bf..7f8bc738499 100644
--- a/Source/WebKit/CMakeLists.txt
+++ b/Source/WebKit/CMakeLists.txt
@@ -598,3 +598,9 @@ else ()
         RUNTIME DESTINATION "${LIBEXEC_INSTALL_DIR}"
     )
 endif ()
+
+target_link_libraries(WebKit PUBLIC
+    -Wl,--whole-archive
+    $<TARGET_PROPERTY:WebKit::JavaScriptCore,INTERFACE_LINK_LIBRARIES>
+    -Wl,--no-whole-archive
+)

…which is an ugly hack, so I am going to close this in favor of
tackling bug #210366 — I'll try and help out Don with that one.

*** This bug has been marked as a duplicate of bug 210366 ***