NEW 179171
[WPE][JHbuild] Gstreamer plugins that link with pango outside of the JHBuild
https://bugs.webkit.org/show_bug.cgi?id=179171
Summary [WPE][JHbuild] Gstreamer plugins that link with pango outside of the JHBuild
Carlos Alberto Lopez Perez
Reported 2017-11-02 07:18:09 PDT
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.
Attachments
Michael Catanzaro
Comment 1 2017-11-02 07:42:32 PDT
Drat. I think we need to roll out r224151 and then land my original patch in that issue.
Carlos Alberto Lopez Perez
Comment 2 2017-11-02 07:59:19 PDT
(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
Comment 3 2017-11-02 08:53:39 PDT
(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
Comment 4 2017-11-02 09:01:41 PDT
(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
Comment 5 2018-01-30 09:40:02 PST
(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
Comment 6 2018-01-30 10:43:48 PST
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
Comment 7 2018-01-31 07:30:54 PST
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
Comment 8 2018-01-31 08:00:37 PST
This seems related to https://trac.webkit.org/changeset/227900/webkit Maybe update your build and check again?
Michael Catanzaro
Comment 9 2018-01-31 08:31:06 PST
(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.
Note You need to log in before you can comment on or make changes to this bug.