LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 03-19-2019, 02:32 PM   #1
jmacloue
LQ Newbie
 
Registered: Apr 2009
Location: Kharkiv, UA
Distribution: Slackware
Posts: 18

Rep: Reputation: 7
Slackware64 14.2 multilib - 32-bit gstreamer problem


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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Slackware64 Multilib: How To find if program to be compiled is 32-bit OR 64-bit fasterbobcatkillkill Slackware 4 01-12-2017 01:28 PM
Building problem of "some" 32-bit programs in Slackware64 multilib aalireza Slackware 1 06-05-2013 08:24 AM
[ANN] mk-slack64-multilib : A tool to create slackware64+multilib tree/iso phenixia2003 Slackware 5 12-28-2012 05:42 AM
upgrading slackware64 13.1 multilib to slackware64 -current multilib Cultist Slackware 4 03-12-2011 09:04 AM
slackware64 + multilib or simply install 32-bit? [GOD]Anck Slackware 1 08-31-2009 03:51 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 11:32 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration