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.)
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 %
*** Bug 200033 has been marked as a duplicate of this bug. ***
(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 ***