[wpe-webkit] What causes symbols to be visible?

[Salisbury, Mark]

Adrian, Konstantin,

Thanks very much.  The linker script was exactly what I was missing.

We have a browser based on the old API - it will run against an older Qt based WebKit port as well.

I expect we'll be moving to the new API before long.  I'd like to be more engaged in pushing work upstream too.  One important thing for us - running on Windows.  We have WPE running on Windows and Linux.  We have a Windows simulator that's important to us.  I know this wasn't of too much interest to you guys earlier, but I think that the work we're doing overlaps with what folks at Sony are doing too, bringing back WK2 on Windows.

Whatever we're doing that's of value to the community I'd like to upstream.

Thanks,
Mark

-----Original Message-----
From: Adrian Perez de Castro <aperez at igalia.com> 
Sent: Monday, August 6, 2018 6:40 AM
To: Salisbury, Mark <mark.salisbury at hp.com>
Cc: webkit-wpe at lists.webkit.org
Subject: Re: [wpe-webkit] What causes symbols to be visible?

Hello Mark,

On Thu, 2 Aug 2018 23:13:54 +0000, "Salisbury, Mark" <mark.salisbury at hp.com> wrote:
 
> I'm still using the old WebKit C API, (for example functions like 
> WKPageLoadURLRequest).
> 
> However, after updating to tip of tree, none of these functions are 
> visible anymore when I try to link a browser using the C API.

We have deprecated and disabled usage of the plain C API in favor of the GLib-based one. This was done some time before the first official stable release (version 2.20.0, on May 18th), in order to avoid third party applications using it because there is no API/ABI stability guarantees for the old C API.

From our own experience the new GLib API is richer and much more convenient to use. I would *very strongly* encourage you to port to the new API and use stable official releases: on top of providing the API/ABI compatibility promise that one would expect from stable releases, new releases are also periodically published—including security updates and advisories.

> Only a few misc methods + glib style API methods are exported:
> 
> $ nm -g -D -C libWPEWebKit-0.1.so | grep -v "U " | more
>          w __cxa_finalize
>          w __gmon_start__
>          w _ITM_deregisterTMCloneTable
>          w _ITM_registerTMCloneTable
>          w _Jv_RegisterClasses
> 003eae11 T NetworkProcessMainUnix
>          w __pthread_key_create
>          w pthread_once
> 003f9ebd T StorageProcessMainUnix
> 00408d6d T webkit_application_info_get_name
> 00408c89 T webkit_application_info_get_type 00408ddd T 
> webkit_application_info_get_version
> ...
> 0042bdb1 T webkit_window_properties_get_resizable
> 0042bce1 T webkit_window_properties_get_scrollbars_visible
> 0042bc9d T webkit_window_properties_get_statusbar_visible
> 0042bc59 T webkit_window_properties_get_toolbar_visible
> 0042b919 T webkit_window_properties_get_type
> 00441d89 T WebProcessMainUnix
> 
> Both types of functions have __attribute__((visibility("default"))) (I 
> checked pre-processor output).
>
> Old C API functions use WK_EXPORT whereas the new glib API uses WEBKIT_API.
> (But again, they both end up being __attribute__((visibility("default"))).
>
> I notice that we're compiling and linking with 
> -fvisibility-inlines-hidden, but not with -fvisibility=hidden...
>
> Any ideas?

As mentioned by Konstantin, we are using a linker script to filter which symbols are ultimately exported by the shared library. While you may be able to make the symbols from the old C API usable again, note that this API may change at any moment, and the corresponding headers are *not* installed anymore.

If there is something you need that is missing from the new GLib-based API, we would appreciate you filing bugs [1] or sending a message to this mailing list to request additions to the API. If you can also explain your use-case it's much more likely that we would look into it :-)

Best regards,

-Adrián

---
[1] https://bugs.webkit.org/