LinuxQuestions.org - Slackware64 14.2 multilib

Spent some time today investigating why Wine 32-bit gstreamer integration won't play anything, found out that current gstreamer compat32 package is in fact broken.

GStreamer is plugin-based so to do anything meaningful it needs a bunch of plugins loaded, and to load them it needs to build a plugin registry first. It does this by invoking a separate helper, /usr/libexec/gstreamer-1.0/gst-plugin-scanner, which dlopen()'s the plugins and sends extracted meta-information back to GStreamer. GStreamer is more or less aware of multilib so it creates separate registry caches under ~/.cache/gstreamer-1.0/ so 64-bit and 32-bit applications will use plugins from /usr/lib64 and /usr/lib respectively.

Unfortunately /usr/libexec prefix is not architecture-specific (unlike /usr/lib64 for /usr/lib, there is no /usr/libexec64) so convertpkg just drops the 32-bit helper - leaving only 64-bit one which comes with the main gstreamer package. As dlopen()'ing 32-bit libraries is impossible for 64-bit applications, all the 32-bit plugins are blacklisted by the helper - leaving registry.i586.dat effectively empty:

Code:

jeff@vsslak:~$ /usr/bin/32/gst-inspect-1.0  

staticelements:  bin: Generic bin

staticelements:  pipeline: Pipeline object



Total count: 89 plugins (88 blacklist entries not shown), 2 features

The 64-bit registry is much bigger, as expected:

Code:

jeff@vsslak:~$ /usr/bin/gst-inspect-1.0 | tail

jpeg:  jpegenc: JPEG image encoder

videomixer:  videomixer: Video mixer 2

ximagesrc:  ximagesrc: Ximage video source

auparse:  auparse: AU audio demuxer

multipart:  multipartmux: Multipart muxer

multipart:  multipartdemux: Multipart demuxer

staticelements:  bin: Generic bin

staticelements:  pipeline: Pipeline object



Total count: 90 plugins (3 blacklist entries not shown), 468 features

Not very useful indeed.

So far I have found a workaround for this issue:

1. Get a 32-bit helper from full 32-bit package and put it at, say, /usr/libexec/gstreamer-1.0/gst-plugins-scanner-32
2. Make 32-bit GStreamer application use it by setting the environment variable:

Code:

export GST_PLUGIN_SCANNER_1_0=/usr/libexec/gstreamer-1.0/gst-plugins-scanner-32

This will however break 64-bit applications so putting this in your ~/.profile is, well, a bad idea.

There is hope that once the registry is built - the applications will happily use it at least for some time so just building the 32-bit registry manually would be enough:

Code:

jeff@nukem:~$ GST_PLUGIN_SCANNER_1_0=/usr/libexec/gstreamer-1.0/gst-plugin-scanner-32 /usr/bin/32/gst-inspect-1.0

...

Total count: 172 plugins (6 blacklist entries not shown), 667 features

jeff@nukem:~$ /usr/bin/32/gst-inspect-1.0 | tail -5

rfbsrc:  rfbsrc: Rfb source

staticelements:  bin: Generic bin

staticelements:  pipeline: Pipeline object



Total count: 172 plugins (6 blacklist entries not shown), 667 features

However if a plugin is added or removed, or maybe some cache TTL expires (not sure how it works in GStreamer) - we're back to square one. What about more proper fix?

For example, Debian guys solve this by putting the helpers under arch-specific prefix instead of generic architecture-unaware /usr/libexec. If the Slackware gstreamer packages had the helpers under, say, /usr/lib64/gstreamer-1.0/helpers/ (which can be achieved by giving gstreamer's ./configure an appropriate --libexecdir=... option - all in line with general Slackware guidelines) then they would be handled properly by convertpkg, and GStreamer would be usable in multilib automatically (note to self: verify this tomorrow). As I checked the only place the path to the helper is mentioned is main libgstreamer-1.0.so, and there is no point in using it elsewhere, so no other software would care.

However Mr Volkerding is not keen on multilib so I'm not sure that he can be convinced to change this... Or maybe? ;)

PS Somehow I didn't find anybody with the same problem - though the 32-bit library and plugins are provided with slackware64-multilib to use with Wine specifically, I didn't find any mention of any problems with them. Sorry if I missed something completely obvious, it's either this - or everybody just use Windows codecs via winetricks.