Using a platform plug-in should not need libWPEBackend-default.so

[aperezdc]

Currently, even if a platform plug-in is loaded (e.g. passing --platform=fdo in the command line), it is still needed to have around a libWPEBackend-default.so shared object, which typically is a symlink to the actual WPE backend being used.

Ideally, when using a Cog platform plug-in, libWPEBackend-default.so should not be needed at all — though of course it could be still be used when running without any platform plug-in.

[clopez]

I confirm the issue.
To get cog working with fdo I need to run on the live system:

ln -s /usr/lib/libWPEBackend-fdo-0.1.so.0 /usr/lib/libWPEBackend-default.so

And then run cog as

cog -P fdo http://igalia.com

If i try to rung without specifying a platform value causes it crashes with

# cog http://igalia.com
(cog:895): Cog-DEBUG: platform_setup: Platform name: (null)
(cog:895): Cog-DEBUG: Instantiating default WPE backend as fall-back.

** (cog:895): CRITICAL **: WebKitWebViewBackend* webkit_web_view_backend_new(wpe_view_backend*, GDestroyNotify, gpointer): assertion 'backend' failed

(cog:895): Cog-ERROR **: Could not instantiate any WPE backend.

I wonder why platform is null? shouldn't default to fdo when cog has been built with fdo support?

[clopez]

Ideally, when using a Cog platform plug-in, libWPEBackend-default.so should not be needed at all — though of course it could be still be used when running without any platform plug-in.

dyz installs this files:

/usr/bin/dyz
/usr/lib/libWPEBackend-default.so
/usr/lib/libWPEBackend-dyz.so
/usr/lib/libwlglue.so

So I guess cog should as well install a libWPEBackend-default.so symlink? This means installing dyz and cog at the same time in a image will cause a conflict and won't be possible.
But I guess that is ok meanwhile a better solution is not found ?

I guess the right solution will be for wpebackend to allow passing a name to the symlink (either via API call or environment variable) instead of hardcoding the value here https://github.com/WebPlatformForEmbedded/WPEBackend/blob/master/src/loader.c#L59 (note the code block above that allows passing use an environment variable, but that only gets built on debug).

// Adding @zdobersek to the CC

[clopez]

@macpijan can you update meta-webkit, rebuild and retry ? Is it fixed?
I already pushed for cog recipe in meta-webkit the patch that I sent here as PR
Igalia/meta-webkit@e984bde

[aperezdc]

After giving this some thought, and discussing with @clopez by chat, ideally we would want the Cog platform plug-in to tell libWPEBackend which WPE backend library it should load. While using the environment variable might work, support for reading it is only available for debug-builds of libWPEBackend. The environment variable is not a great option, and it would be highly desirable that libWPEBackend would provide some API to either tell it which shared object to load as WPE backend.

[aperezdc]

Like I mentioned in #12 already, I would rather go with the implementation proposed by @carlosgcampos in WebKit#186841 and WebPlatformForEmbedded/libwpe#18, which adds API to set the path to the WPE backend library, and passing it down to WPEWebProcess.