Bug 179171 – [WPE][JHbuild] Gstreamer plugins that link with pango outside of the JHBuild

• Component: WPE WebKit
• Status: NEW

[Carlos Alberto Lopez Perez]

Starting the WPE minibrowser (dyz) from a clean build (of the JHBuild) I see this warnings


$ WAYLAND_DISPLAY=wayland-0 Tools/Scripts/run-minibrowser --wpe
Starting dyz 
xkbcommon: ERROR: couldn't find a Compose file for locale "C"
GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings will not be saved or shared with other applications.


(gst-plugin-scanner:9478): GStreamer-WARNING **: Failed to load plugin '/home/clopez/webkit/wpe/WebKitBuild/DependenciesWPE/Root/lib/gstreamer-1.0/libgstopencv.so': /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0: undefined symbol: hb_glib_get_unicode_funcs

(gst-plugin-scanner:9479): GStreamer-WARNING **: Failed to load plugin '/home/clopez/webkit/wpe/WebKitBuild/DependenciesWPE/Root/lib/gstreamer-1.0/libgstrsvg.so': /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0: undefined symbol: hb_glib_get_unicode_funcs




The warnings won't appear on the second run, as GStreamer will blacklist this modules on the local registry after detecting this and won't try again to load them.
That's because we are not building pPngo on the JHBuild and its picking the system-wide one, causing this problem.


A very similar issue was reported on bug 178918.

[Michael Catanzaro]

Drat. I think we need to roll out r224151 and then land my original patch in that issue.

[Carlos Alberto Lopez Perez]

(In reply to Michael Catanzaro from comment #1)
> Drat. I think we need to roll out r224151 and then land my original patch in
> that issue.

I also think that building pango on the jhbuild (even when not stricly needed) is less problematic that keep finding and disabling broken gstreamer modules...

Also.. doesn't GStreamer needs pango for subtitle rendering? I think WPE supports this. (Adding miguel to the CC).

[Michael Catanzaro]

(In reply to Carlos Alberto Lopez Perez from comment #2)
> I also think that building pango on the jhbuild (even when not stricly
> needed) is less problematic that keep finding and disabling broken gstreamer
> modules...

It's true, though, that pango is not the only potentially-problematic module we might have here.

We should not really be loading any system-installed GStreamer modules. JHBuild has the following code in environment.py that's presumably supposed to prevent this:

    # GST_PLUGIN_PATH
    gstplugindir = os.path.join(libdir , 'gstreamer-0.10')
    if os.path.exists(gstplugindir):
        addpath('GST_PLUGIN_PATH', gstplugindir)

    # GST_PLUGIN_PATH_1_0
    gstplugindir = os.path.join(libdir , 'gstreamer-1.0')
    if os.path.exists(gstplugindir):
        addpath('GST_PLUGIN_PATH_1_0', gstplugindir)

    # GST_REGISTRY
    gstregistry = os.path.join(prefix, '_jhbuild', 'gstreamer-0.10.registry')
    os.environ['GST_REGISTRY'] = gstregistry

    # GST_REGISTRY_1_0
    gstregistry = os.path.join(prefix, '_jhbuild', 'gstreamer-1.0.registry')
    os.environ['GST_REGISTRY_1_0'] = gstregistry

I'm not sure why it doesn't work.

> Also.. doesn't GStreamer needs pango for subtitle rendering? I think WPE
> supports this. (Adding miguel to the CC).

Another reason to revert r224151, then.

[Michael Catanzaro]

(In reply to Carlos Alberto Lopez Perez from comment #2)
> Also.. doesn't GStreamer needs pango for subtitle rendering? I think WPE
> supports this. (Adding miguel to the CC).

I might be wrong, but I think that's ENABLE_VIDEO_TRACK, which is PRIVATE and OFF upstream.

[Philippe Normand]

(In reply to Michael Catanzaro from comment #4)
> (In reply to Carlos Alberto Lopez Perez from comment #2)
> > Also.. doesn't GStreamer needs pango for subtitle rendering? I think WPE
> > supports this. (Adding miguel to the CC).
> 
> I might be wrong, but I think that's ENABLE_VIDEO_TRACK, which is PRIVATE
> and OFF upstream.

It's PRIVATE and *ON* upstream.
Yes pango is required for subtitles rendering.
Yes pango should be built in jhbuild.

[Michael Catanzaro]

So the problem is:

(In reply to Michael Catanzaro from comment #3)
> We should not really be loading any system-installed GStreamer modules.
> JHBuild has the following code in environment.py that's presumably supposed
> to prevent this:
> 
>     # GST_PLUGIN_PATH
>     gstplugindir = os.path.join(libdir , 'gstreamer-0.10')
>     if os.path.exists(gstplugindir):
>         addpath('GST_PLUGIN_PATH', gstplugindir)
> 
>     # GST_PLUGIN_PATH_1_0
>     gstplugindir = os.path.join(libdir , 'gstreamer-1.0')
>     if os.path.exists(gstplugindir):
>         addpath('GST_PLUGIN_PATH_1_0', gstplugindir)
> 
>     # GST_REGISTRY
>     gstregistry = os.path.join(prefix, '_jhbuild', 'gstreamer-0.10.registry')
>     os.environ['GST_REGISTRY'] = gstregistry
> 
>     # GST_REGISTRY_1_0
>     gstregistry = os.path.join(prefix, '_jhbuild', 'gstreamer-1.0.registry')
>     os.environ['GST_REGISTRY_1_0'] = gstregistry
> 
> I'm not sure why it doesn't work.

[Philippe Normand]

No this isn't a $GST* env var issue. The plugins that fail to load where built by jhbuild: DependenciesWPE/Root/lib/gstreamer-1.0/libgstrsvg.so

But they depend on a library not part of the jhbuild: libpangoft2-1.0.so. Seems like enabling harfbuzz in jhbuild would fix this?

[Philippe Normand]

This seems related to https://trac.webkit.org/changeset/227900/webkit
Maybe update your build and check again?

[Michael Catanzaro]

(In reply to Philippe Normand from comment #7)
> No this isn't a $GST* env var issue. The plugins that fail to load where
> built by jhbuild: DependenciesWPE/Root/lib/gstreamer-1.0/libgstrsvg.so
> 
> But they depend on a library not part of the jhbuild: libpangoft2-1.0.so.
> Seems like enabling harfbuzz in jhbuild would fix this?

Does the --with-glib=yes flag control whether libpangoft2-1.0.so is built?

Note: harfbuzz in the GTK+ JHBuild moduleset does not use --with-glib=yes and does not have an explicit dependency on GLib. We're playing with fire there.