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.
Drat. I think we need to roll out r224151 and then land my original patch in that issue.
(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).
(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.
(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.
(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.
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.
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?
This seems related to https://trac.webkit.org/changeset/227900/webkit Maybe update your build and check again?
(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.