So I ran into an issue 3 years ago where the 32-bit GStreamer plugins are unusable on Fedora and openSUSE despite these distributions shipping the needed 32-bit packages.
So did anyone manage to get winegstreamer.dll to work for 32-bit Windows applications on Fedora and openSUSE or is it widely known that one should avoid them when using Wine?
Note that of course I reported this issue to the distributions and this is where you'll find more details about this issue:
* Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1472160 -> Reported against Fedora 26, then 28, still present in Fedora 32 but fixing this bug seems to have been postponed indefinitely.
* openSUSE https://bugzilla.opensuse.org/show_bug.cgi?id=1049452 -> Supposedly fixed on Tumbleweed 2 years ago but still present on openSUSE Leap 15.1
https://bugzilla.opensuse.org/show_bug.cgi?id=1172018 -> New bug for openSUSE Leap 15.1.
On Sat, 23 May 2020 19:29:30 +0200 (CEST) Francois Gouget fgouget@free.fr wrote:
So did anyone manage to get winegstreamer.dll to work for 32-bit Windows applications on Fedora and openSUSE or is it widely known that one should avoid them when using Wine?
About the only thing I ever used winegstreamer for was for embedded videos in Powerpoint and I haven't needed that in awhile, but I just fired up an old Powerpoint with an embedded video that I had used for testing and it is still working in Powerpoint 7 and 10 in Wine 5.9 on openSUSE Leap 15.0.
On Sat, 23 May 2020, Rosanne DiMesio wrote: [...]
About the only thing I ever used winegstreamer for was for embedded videos in Powerpoint and I haven't needed that in awhile, but I just fired up an old Powerpoint with an embedded video that I had used for testing and it is still working in Powerpoint 7 and 10 in Wine 5.9 on openSUSE Leap 15.0.
Is it a 64-bit version of MS Office? If not I suspect it's not using winegstreamer. Does the video still play if you rename winegstreamer.dll to winegstreamer.dll.ignore?
I did that test with an mpeg 1 video embedded in a PowerPoint 2000 presentation and the video stopped playing when I removed winegstreamer.dll.
gstreamer 32 bit was long broken on Fedora in the past due to ever broken dependencies of gst-plugins-bad and gst-plugins-ugly. But that was fixed in the middle of Fedora 31 and is still ok now in Fedora 32. winegstreamer used to work fine for me in the games I tried since then (i. e., there weren’t gst related problems anymore).
I am not sure I ever saw a problem discussed in the referenced bug report, but I did not try to reproduce with clean Fedora install.
On 23 May 2020, at 20:30, Francois Gouget fgouget@free.fr wrote:
So I ran into an issue 3 years ago where the 32-bit GStreamer plugins are unusable on Fedora and openSUSE despite these distributions shipping the needed 32-bit packages.
So did anyone manage to get winegstreamer.dll to work for 32-bit Windows applications on Fedora and openSUSE or is it widely known that one should avoid them when using Wine?
Note that of course I reported this issue to the distributions and this is where you'll find more details about this issue:
- Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=1472160 -> Reported against Fedora 26, then 28, still present in Fedora 32 but fixing this bug seems to have been postponed indefinitely.
- openSUSE
https://bugzilla.opensuse.org/show_bug.cgi?id=1049452 -> Supposedly fixed on Tumbleweed 2 years ago but still present on openSUSE Leap 15.1
https://bugzilla.opensuse.org/show_bug.cgi?id=1172018 -> New bug for openSUSE Leap 15.1.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.
On Sun, 24 May 2020, Paul Gofman wrote:
gstreamer 32 bit was long broken on Fedora in the past due to ever broken dependencies of gst-plugins-bad and gst-plugins-ugly.
That seems like totally unrelated issues (most distributions are missing one gstreamer plugin or another).
But that was fixed in the middle of Fedora 31 and is still ok now in Fedora 32. winegstreamer used to work fine for me in the games I tried since then (i. e., there weren’t gst related problems anymore).
That's very surprising. I tested this on Fedora 32 yesterday and the bug was definitely still present.
Are you sure these are 32-bit games and that they use winegstreamer.dll? How can winegstreamer find the 32-bit plugins if gst-plugin-scanner cannot even load the plugin libraries?
Or maybe the 32-bit GStreamer plugins work but not the 64-bit ones... What do you get for these commands:
rpm -qf /usr/libexec/gstreamer-1.0/gst-plugin-scanner rpm -qf /usr/bin/gst-inspect-1.0 gst-inspect-1.0 videoconvert | grep Filename
(and for that matter, what about the steps to reproduce in the bug?)
On 5/24/20 17:22, Francois Gouget wrote:
That's very surprising. I tested this on Fedora 32 yesterday and the bug was definitely still present.
Admittedly, my comment of being unable to reproduce the referenced bug was misleading, I actually never tried installing distro-provided 32-bit client tools, only libraries. My reply was concerning winegstreamer
Are you sure these are 32-bit games and that they use winegstreamer.dll? How can winegstreamer find the 32-bit plugins if gst-plugin-scanner cannot even load the plugin libraries?
Yes, the first example out of my head is Blaz Blue Calamity Trigger from Steam which I was testing. It is 32 bit and winegstreamer definitely worked here. There was a problem with missing sound when playing movie which I debugged but that was not related to gstreamer, and MPEG video was playing OK.
Or maybe the 32-bit GStreamer plugins work but not the 64-bit ones... What do you get for these commands:
rpm -qf /usr/libexec/gstreamer-1.0/gst-plugin-scanner rpm -qf /usr/bin/gst-inspect-1.0 gst-inspect-1.0 videoconvert | grep Filename
$ rpm -qf /usr/libexec/gstreamer-1.0/gst-plugin-scanner
gstreamer1-1.16.2-2.fc32.x86_64
$ rpm -qf /usr/bin/gst-inspect-1.0 gstreamer1-1.16.2-2.fc32.x86_64
$ gst-inspect-1.0 videoconvert | grep Filename Filename /usr/lib64/gstreamer-1.0/libgstvideoconvert.so
(all that is apparently 64 bit stuff, I didn't ever install 32 bit distro provided gst client tools manually).
On Sun, 24 May 2020, Paul Gofman wrote: [...]
$ rpm -qf /usr/libexec/gstreamer-1.0/gst-plugin-scanner
gstreamer1-1.16.2-2.fc32.x86_64
This is the binary that maps element names like videoconvert to the name of the library to load, here /usr/lib64/gstreamer-1.0/libgstvideoconvert.so. Since it's a 64-bit binary (maybe a file would have been stronger proof), it cannot build the 32-bit registry.
$ rpm -qf /usr/bin/gst-inspect-1.0 gstreamer1-1.16.2-2.fc32.x86_64
$ gst-inspect-1.0 videoconvert | grep Filename Filename /usr/lib64/gstreamer-1.0/libgstvideoconvert.so
This is the library that provides the videoconvert plugin and since it's a 64-bit library that means 32-bit processes cannot use it, winegstreamer included... unless it has some cross-process communication mechanism so that all GStreamer code in fact runs in a 64-bit process (that seems highly unlikely).
It looks like Blaz Blue Calamity Trigger has a 64-bit version. Could it be that's the one you're actually running?
If not, does its behavior change if you rename winegstreamer.dll so it's not used?
On 5/24/20 18:53, Francois Gouget wrote:
On Sun, 24 May 2020, Paul Gofman wrote: [...]
$ rpm -qf /usr/libexec/gstreamer-1.0/gst-plugin-scanner
gstreamer1-1.16.2-2.fc32.x86_64
This is the binary that maps element names like videoconvert to the name of the library to load, here /usr/lib64/gstreamer-1.0/libgstvideoconvert.so. Since it's a 64-bit binary (maybe a file would have been stronger proof), it cannot build the 32-bit registry.
$ rpm -qf /usr/bin/gst-inspect-1.0 gstreamer1-1.16.2-2.fc32.x86_64
$ gst-inspect-1.0 videoconvert | grep Filename Filename /usr/lib64/gstreamer-1.0/libgstvideoconvert.so
This is the library that provides the videoconvert plugin and since it's a 64-bit library that means 32-bit processes cannot use it, winegstreamer included... unless it has some cross-process communication mechanism so that all GStreamer code in fact runs in a 64-bit process (that seems highly unlikely).
winegstreamer is not using command line gstreamer tools, I guess, only libraries. Of course I have 32 bit ones installed, just gst-... tools won't show that since they are 64 bit.
It looks like Blaz Blue Calamity Trigger has a 64-bit version. Could it be that's the one you're actually running?
No, as far as I am aware. I was running 32 bit one. It is a rather old XP-compatible game. I am unlikely totally mistaken here as I did have a lot of problems with 32 bit gstreamer (mostly not working in any games I saw using it), and spent exciting hours trying to build gst with all the plugins and dependencies myself (sadly, without total success), until 32 bit plugins were fixed.
If not, does its behavior change if you rename winegstreamer.dll so it's not used?
I have deleted the game long ago. I could probably find some game using winegstreamer and find out what winegstreamer is doing here, but maybe it is more practical to wait for some comment from someone who has hands on winegstreamer (*thinks of Zebediah Figura *)
On 5/24/20 11:02 AM, Paul Gofman wrote:
On 5/24/20 18:53, Francois Gouget wrote:
On Sun, 24 May 2020, Paul Gofman wrote: [...]
$ rpm -qf /usr/libexec/gstreamer-1.0/gst-plugin-scanner
gstreamer1-1.16.2-2.fc32.x86_64
This is the binary that maps element names like videoconvert to the name of the library to load, here /usr/lib64/gstreamer-1.0/libgstvideoconvert.so. Since it's a 64-bit binary (maybe a file would have been stronger proof), it cannot build the 32-bit registry.
$ rpm -qf /usr/bin/gst-inspect-1.0 gstreamer1-1.16.2-2.fc32.x86_64
$ gst-inspect-1.0 videoconvert | grep Filename Filename /usr/lib64/gstreamer-1.0/libgstvideoconvert.so
This is the library that provides the videoconvert plugin and since it's a 64-bit library that means 32-bit processes cannot use it, winegstreamer included... unless it has some cross-process communication mechanism so that all GStreamer code in fact runs in a 64-bit process (that seems highly unlikely).
winegstreamer is not using command line gstreamer tools, I guess, only libraries. Of course I have 32 bit ones installed, just gst-... tools won't show that since they are 64 bit.
Yes, this is correct. winegstreamer doesn't use tool programs at all, and libgstreamer doesn't depend on them either.
Of course, it'd be nice if they were fixed to be properly multiarch-compatible, but it shouldn't prevent winegstreamer from working.
It looks like Blaz Blue Calamity Trigger has a 64-bit version. Could it be that's the one you're actually running?
No, as far as I am aware. I was running 32 bit one. It is a rather old XP-compatible game. I am unlikely totally mistaken here as I did have a lot of problems with 32 bit gstreamer (mostly not working in any games I saw using it), and spent exciting hours trying to build gst with all the plugins and dependencies myself (sadly, without total success), until 32 bit plugins were fixed.
If not, does its behavior change if you rename winegstreamer.dll so it's not used?
I have deleted the game long ago. I could probably find some game using winegstreamer and find out what winegstreamer is doing here, but maybe it is more practical to wait for some comment from someone who has hands on winegstreamer (*thinks of Zebediah Figura *)
On Sun, 24 May 2020, Zebediah Figura wrote: [...]
Yes, this is correct. winegstreamer doesn't use tool programs at all, and libgstreamer doesn't depend on them either.
Whether winegstreamer uses the tool programs or not is a red herring. The GStreamer tools just provide a 3 lines 32-bit process testcase. But we can also got the hard way to reproduce this problem:
winegstreamer needs gst_element_factory_make() to work. From various functions in dlls/winegstreamer/gstdemux.c: if (!(vconv = gst_element_factory_make("videoconvert", NULL))) if (!(convert = gst_element_factory_make("audioconvert", NULL))) GstElement *element = gst_element_factory_make("decodebin", NULL);
So let's test this out in a simple 32-bit program:
----- checkgst.c ----- /* gcc -m32 -o checkgst32 `PKG_CONFIG_PATH=/usr/lib/i386-linux-gnu/pkgconfig:/usr/lib/pkgconfig pkg-config --cflags --libs gstreamer-1.0` checkgst.c */ #include <stdio.h> #include <string.h> #include <gst/gst.h>
static void check_gstreamer_element(const char *name) { GstElement *element = gst_element_factory_make(name, NULL); if (element) { printf("found %s\n", name); gst_object_unref(element); } else printf("could not instantiate %s\n", name); }
int main(int argc, char** argv) { gst_init(&argc, &argv); printf("Bitness: %d bits\n", sizeof(long) * 8); check_gstreamer_element("h264parse"); /* gstreamer-plugins-bad */ check_gstreamer_element("videoconvert"); /* gstreamer-plugins-base */ check_gstreamer_element("vp8dec"); /* gstreamer-plugins-good */ check_gstreamer_element("mpeg2dec"); /* gstreamer-plugins-ugly */ return 0; } ----- checkgst.c -----
Just as a note for myself, from a clean install one needs the following packages to compile it:
# dnf install glibc-devel.x86_64 glibc-devel.i686 # dnf install gstreamer1-devel.x86_64 gstreamer1-devel.i686 # # In fact we really only need one plugin package # dnf install gstreamer1-plugins-base.i686 gstreamer1-plugins-good.i686 # dnf install gstreamer1-plugins-bad-free.i686 gstreamer1-plugins-ugly-free.i686
And do a 32-bit test:
$ gcc -m32 -o checkgst32 `PKG_CONFIG_PATH=/usr/lib/pkgconfig pkg-config --cflags --libs gstreamer-1.0` checkgst.c $ ./checkgst32 Bitness: 32 bits could not instantiate h264parse could not instantiate videoconvert could not instantiate vp8dec could not instantiate mpeg2dec
Let's try again with a 64-bit binary to make sure this program can actually work:
$ gcc -o checkgst64 `pkg-config --cflags --libs gstreamer-1.0` checkgst.c $ ./checkgst64 Bitness: 64 bits found h264parse found videoconvert found vp8dec found mpeg2dec
And a last check to pinpoint the source of the problem:
$ mv ~/.cache/gstreamer-1.0/registry.i686.bin ~/.cache/gstreamer-1.0/registry.i686.bin.sav $ ./checkgst32 (gst-plugin-scanner:7151): GStreamer-WARNING **: 12:12:57.971: Failed to load plugin '/usr/lib/gstreamer-1.0/libgstdvb.so': /usr/lib/gstreamer-1.0/libgstdvb.so: wrong ELF class: ELFCLASS32
(gst-plugin-scanner:7151): GStreamer-WARNING **: 12:12:57.971: Failed to load plugin '/usr/lib/gstreamer-1.0/libgstvideo4linux2.so': /usr/lib/gstreamer-1.0/libgstvideo4linux2.so: wrong ELF class: ELFCLASS32 [...] Bitness: 32 bits could not instantiate h264parse could not instantiate videoconvert could not instantiate vp8dec could not instantiate mpeg2dec
As for where gst-plugin-scanner comes from and why gst_element_factory_make() may need it, I'll point you to the bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1472160
(and then we can debate whether gst-plugin-scanner is a GStreamer command line tool and whether that means winegstreamer does depend on GStreamer command line tools)
On 5/25/20 13:31, Francois Gouget wrote:
Just as a note for myself, from a clean install one needs the following packages to compile it:
# dnf install glibc-devel.x86_64 glibc-devel.i686 # dnf install gstreamer1-devel.x86_64 gstreamer1-devel.i686 # # In fact we really only need one plugin package # dnf install gstreamer1-plugins-base.i686 gstreamer1-plugins-good.i686 # dnf install gstreamer1-plugins-bad-free.i686 gstreamer1-plugins-ugly-free.i686
In case it helps, here is the list of my installed gst-related i686 packages:
gstream-1.6-23.fc32.i686 gstreamer1-plugins-fc-0.2-22.fc32.i686 gstreamer1-plugins-ugly-free-1.16.2-2.fc32.i686 gstreamer1-1.16.2-2.fc32.i686 gstreamer1-plugins-bad-free-1.16.2-3.fc32.i686 gstreamer1-devel-1.16.2-2.fc32.i686 gstreamer1-libav-1.16.2-3.fc32.i686 phonon-qt4-backend-gstreamer-4.9.1-10.fc32.i686 gstreamer1-plugins-good-extras-1.16.2-2.fc32.i686 gstreamer1-plugins-good-1.16.2-2.fc32.i686 gstreamer1-plugins-ugly-1.16.2-3.fc32.i686 gstream-devel-1.6-23.fc32.i686 gstreamer1-plugins-good-qt-1.16.2-2.fc32.i686 gstreamer1-plugins-ugly-free-devel-1.16.2-2.fc32.i686 gstreamer1-plugins-base-1.16.2-3.fc32.i686 gstreamer1-plugins-good-gtk-1.16.2-2.fc32.i686 gstreamer1-plugin-openh264-1.16.2-1.fc32.i686 gstreamer1-plugins-base-devel-1.16.2-3.fc32.i686
Packaging is not my thing and I did not ever try to guess which of that is really needed and which is not, but that's how it works here. Also it is possible I had to use explicit PKG_CONFIG_PATH=/usr/lib/pkgconfig when configuring / compiling 32 bit part of Wine to get gst libraries right.
On Mon, 25 May 2020, Paul Gofman wrote: [...]
In case it helps, here is the list of my installed gst-related i686 packages:
gstream-1.6-23.fc32.i686 gstreamer1-plugins-fc-0.2-22.fc32.i686 gstreamer1-plugins-ugly-free-1.16.2-2.fc32.i686 gstreamer1-1.16.2-2.fc32.i686 gstreamer1-plugins-bad-free-1.16.2-3.fc32.i686 gstreamer1-devel-1.16.2-2.fc32.i686 gstreamer1-libav-1.16.2-3.fc32.i686 phonon-qt4-backend-gstreamer-4.9.1-10.fc32.i686 gstreamer1-plugins-good-extras-1.16.2-2.fc32.i686 gstreamer1-plugins-good-1.16.2-2.fc32.i686 gstreamer1-plugins-ugly-1.16.2-3.fc32.i686 gstream-devel-1.6-23.fc32.i686 gstreamer1-plugins-good-qt-1.16.2-2.fc32.i686 gstreamer1-plugins-ugly-free-devel-1.16.2-2.fc32.i686 gstreamer1-plugins-base-1.16.2-3.fc32.i686 gstreamer1-plugins-good-gtk-1.16.2-2.fc32.i686 gstreamer1-plugin-openh264-1.16.2-1.fc32.i686 gstreamer1-plugins-base-devel-1.16.2-3.fc32.i686
dnf did not find gstreamer1-libav.i686 and gstreamer1-plugins-ugly.i686. Do you know which repository they come from?
I installed all the other packages but it does not make a difference.
Also it is possible I had to use explicit PKG_CONFIG_PATH=/usr/lib/pkgconfig when configuring / compiling 32 bit part of Wine to get gst libraries right.
That's not necessary. configure does this for you:
$ grep PKG_CONFIG_PATH configure.ac PKG_CONFIG_PATH=${PKG_CONFIG_PATH:-/usr/lib/i386-linux-gnu/pkgconfig:/usr/lib32/pkgconfig:/usr/lib/pkgconfig} export PKG_CONFIG_PATH
On 5/25/20 15:11, Francois Gouget wrote:
On Mon, 25 May 2020, Paul Gofman wrote: [...] dnf did not find gstreamer1-libav.i686 and gstreamer1-plugins-ugly.i686. Do you know which repository they come from?
Oh, those are from rpmfusion-free (https://rpmfusion.org/). I guess quite a lot of things in Fedora are not immediately usable without rpmfusion.
On Mon, 25 May 2020 15:33:01 +0300 Paul Gofman pgofman@codeweavers.com wrote:
Oh, those are from rpmfusion-free (https://rpmfusion.org/). I guess quite a lot of things in Fedora are not immediately usable without rpmfusion.
OpenSUSE has a similar situation with Packman.
On Mon, 25 May 2020, Paul Gofman wrote:
On 5/25/20 15:11, Francois Gouget wrote:
On Mon, 25 May 2020, Paul Gofman wrote: [...] dnf did not find gstreamer1-libav.i686 and gstreamer1-plugins-ugly.i686. Do you know which repository they come from?
Oh, those are from rpmfusion-free (https://rpmfusion.org/). I guess quite a lot of things in Fedora are not immediately usable without rpmfusion.
I added RPMFusion and installed these two packages but as expected they do not make any difference. I also checked which other GStreamer packages RPMFusion has but it's all plugins which is not going to make any difference here.
Did you try the checkgst32 tool? Particularly after deleting / moving away ~/.cache/gstreamer-1.0/registry.i686.bin.
The output from this would help figure out what's going on too:
rm ~/.cache/gstreamer-1.0/registry.i686.bin; GST_DEBUG=9 GST_DEBUG_COLOR_MODE=off ./checkgst32 2>&1| tee checkgst32.log
(look for scanner; I'd be interested in this file)
Interestingly a workaround for this issue is to delete / move away /usr/libexec/gstreamer-1.0/gst-plugin-scanner and delete registry.i686.bin. Then 32- and 64-bit processes alike do the scanning themselves and both work (and recreate the registry files). Also once registry.i686.bin has been updated gst-plugin-scanner can be moved back in place and the plugins that are in registry.i686.bin still work. Of course if you installed new GStreamer plugins they this procedure would need to be repeated (and this would need to be repeated for each account).
Also note that setting GST_PLUGIN_SCANNER / GST_PLUGIN_SCANNER_1_0 to a bad file does not work because gstpluginloader.c then falls back to the 'installed' one.
On 5/26/20 12:41, Francois Gouget wrote:
Did you try the checkgst32 tool? Particularly after deleting / moving away ~/.cache/gstreamer-1.0/registry.i686.bin.
Sorry I might have missed something but where can I find this tool?
Interestingly a workaround for this issue is to delete / move away /usr/libexec/gstreamer-1.0/gst-plugin-scanner and delete registry.i686.bin. Then 32- and 64-bit processes alike do the scanning themselves and both work (and recreate the registry files). Also once registry.i686.bin has been updated gst-plugin-scanner can be moved back in place and the plugins that are in registry.i686.bin still work.
So maybe the key to success here is not having 32 bit gst-plugin-scanner installed, or even 64 bit gst-plugin-scanner being not available through auto search path?
On Tue, 26 May 2020, Paul Gofman wrote:
On 5/26/20 12:41, Francois Gouget wrote:
Did you try the checkgst32 tool? Particularly after deleting / moving away ~/.cache/gstreamer-1.0/registry.i686.bin.
Sorry I might have missed something but where can I find this tool?
Here: https://www.winehq.org/pipermail/wine-devel/2020-May/166719.html
[...]
So maybe the key to success here is not having 32 bit gst-plugin-scanner installed,
I don't know of a way of getting the 32-bit gst-plugin-scanner installed on Fedora, short of using rpm2cpio on the 32-bit package and then copying it in place.
or even 64 bit gst-plugin-scanner being not available through auto search path?
gst-plugin-scanner is installed by gstreamer1.x86_64. So again the only way to not have it while still being able to use GStreamer is to go the full manual route and sudo rm gst-plugin-scanner.
(I'm not quite sure I understand 'auto search path' though)
On 5/26/20 18:11, Francois Gouget wrote:
gst-plugin-scanner is installed by gstreamer1.x86_64. So again the only way to not have it while still being able to use GStreamer is to go the full manual route and sudo rm gst-plugin-scanner.
(I'm not quite sure I understand 'auto search path' though)
I've run the program, and it doesn't find plugins right away, it also doesn't find them after deleting cache. But after 'mv /usr/libexec/gstreamer-1.0/gst-plugin-scanner /usr/libexec/gstreamer-1.0/gst-plugin-scanner.bckp' and clearing the cache it works fine (with cache or not). It also works fine if you get the gst-plugin-scanner back and keep the cache now.
But I sure did not ever removed gst-plugins-scanner previously (could clean the caches though maybe). Can it be winegstreamer does something a bit different and thus avoids the bad influence of scanner?
On Tue, 26 May 2020, Paul Gofman wrote:
On 5/26/20 18:11, Francois Gouget wrote:
gst-plugin-scanner is installed by gstreamer1.x86_64. So again the only way to not have it while still being able to use GStreamer is to go the full manual route and sudo rm gst-plugin-scanner.
(I'm not quite sure I understand 'auto search path' though)
I've run the program, and it doesn't find plugins right away, it also doesn't find them after deleting cache. But after 'mv /usr/libexec/gstreamer-1.0/gst-plugin-scanner /usr/libexec/gstreamer-1.0/gst-plugin-scanner.bckp' and clearing the cache it works fine (with cache or not). It also works fine if you get the gst-plugin-scanner back and keep the cache now.
Good. That matches what I get.
But I sure did not ever removed gst-plugins-scanner previously (could clean the caches though maybe). Can it be winegstreamer does something a bit different and thus avoids the bad influence of scanner?
Ah! Found it:
static BOOL CALLBACK init_gstreamer_proc(INIT_ONCE *once, void *param, void **ctx) { BOOL *status = param; char argv0[] = "wine"; char argv1[] = "--gst-disable-registry-fork"; [...] *status = gst_init_check(&argc, &argv, &err);
So it's --gst-disable-registry-fork that does the trick and it does indeed saves Wine from this bug.
On Sat, May 23, 2020 at 07:29:30PM +0200, Francois Gouget wrote:
So I ran into an issue 3 years ago where the 32-bit GStreamer plugins are unusable on Fedora and openSUSE despite these distributions shipping the needed 32-bit packages.
So did anyone manage to get winegstreamer.dll to work for 32-bit Windows applications on Fedora and openSUSE or is it widely known that one should avoid them when using Wine?
Note that of course I reported this issue to the distributions and this is where you'll find more details about this issue:
Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1472160 -> Reported against Fedora 26, then 28, still present in Fedora 32 but fixing this bug seems to have been postponed indefinitely.
openSUSE https://bugzilla.opensuse.org/show_bug.cgi?id=1049452 -> Supposedly fixed on Tumbleweed 2 years ago but still present on openSUSE Leap 15.1
https://bugzilla.opensuse.org/show_bug.cgi?id=1172018 -> New bug for openSUSE Leap 15.1.
Tumbleweed and 15.x have divergent codebases for gstreamer... and I lost track of this.
I will see that i get this moving towards 15.1/15.2.
Ciao, Marcus
On Sat, 23 May 2020 19:29:30 +0200 (CEST) Francois Gouget fgouget@free.fr wrote:
https://bugzilla.opensuse.org/show_bug.cgi?id=1172018 -> New bug for openSUSE Leap 15.1.
In that bug you say:
As a result ~/.cache/gstreamer-1.0/registry.i586.bin is empty
FWIW, my ~/.cache/gstreamer-1.0 directory has both registry.i586.bin and registry.x86_64.bin, and neither one is empty. And my /usr/lib/gstreamer-1.0/gst-plugin-scanner is 64 bit.
However I have not figured out how to compile it from a clean 64-bit openSUSE 15.1 install because there is no gstreamer-devel-32bit package!
I only have gstreamer-devel installed and I am able to build 32 bit Wine with gstreamer support on my 64 bit openSUSE system. I wrote a pretty detailed how-to on https://wiki.winehq.org/OpenSUSE. Admittedly, it's old and needs updating--some new dependencies have been added since it was written--but it gives some very specific advice about gstreamer.
On Mon, 25 May 2020, Rosanne DiMesio wrote: [...]
On Sat, 23 May 2020 19:29:30 +0200 (CEST) Francois Gouget fgouget@free.fr wrote:
https://bugzilla.opensuse.org/show_bug.cgi?id=1172018 -> New bug for openSUSE Leap 15.1.
In that bug you say:
As a result ~/.cache/gstreamer-1.0/registry.i586.bin is empty
FWIW, my ~/.cache/gstreamer-1.0 directory has both registry.i586.bin and registry.x86_64.bin, and neither one is empty. And my /usr/lib/gstreamer-1.0/gst-plugin-scanner is 64 bit.
Right, I used 'empty' in a somewhat loose sense. registry.i586.bin is small (<= 25kB instead of > 200kB) and running strings on it shows all plugins are blacklisted:
$ strings .cache/gstreamer-1.0/registry.i586.bin | head -n12 1.3.0 libgstcoreelements.so Plugin for blacklisted file /usr/lib/gstreamer-1.0/libgstcoreelements.so 0.0.0 BLACKLIST BLACKLIST BLACKLIST BLACKLIST libgstcoretracers.so Plugin for blacklisted file /usr/lib/gstreamer-1.0/libgstcoretracers.so
That's a clear result of the 64-bit gst-plugin-scanner being unable to load the libraries to see what they contain. Contrast it with the 64-bit file:
$ strings .cache/gstreamer-1.0/registry.x86_64.bin | head -n12 1.3.0 coreelements GStreamer core elements /usr/lib64/gstreamer-1.0/libgstcoreelements.so 1.12.5 LGPL gstreamer openSUSE GStreamer package http://download.opensuse.org 2018-03-28 GstElementFactory capsfilter
However I have not figured out how to compile it from a clean 64-bit openSUSE 15.1 install because there is no gstreamer-devel-32bit package!
I only have gstreamer-devel installed and I am able to build 32 bit Wine with gstreamer support on my 64 bit openSUSE system. I wrote a pretty detailed how-to on https://wiki.winehq.org/OpenSUSE. Admittedly, it's old and needs updating--some new dependencies have been added since it was written--but it gives some very specific advice about gstreamer.
That's a pretty interesting page. I took the instructions and integrated them in the wt-install-dev script I maintain for wt-daily (for running the Wine tests daily).
It has the advantage of making the instructions testable, reproducible and hopefully easier to run:
wget https://raw.githubusercontent.com/fgouget/wt-daily/master/wt-install-dev && sh wt-install-dev
Here are some things I found while writing / testing it on openSUSE 15.1:
* MinGW does not seem to be readily available. Compiling Wine without MinGW is likely not to get tested much in the future so that's concerning.
* A number of -devel-32bit packages don't depend on package that contains the libraries, resulting in unusable dead links. The culprits are: fontconfig-devel-32bit libgphoto2-devel-32bit libpulse-devel-32bit libv4l-devel-32bit openal-soft-devel-32bit sane-backends-devel-32bit vulkan-devel-32bit
* gstreamer-devel-32bit is missing but installing glib2-devel-32bit and creating some symlinks seems to be enough to compile 32-bit GStreamer applications. That's good.
* There are a couple other missing -devel-32bit packages that the script works around by creating the missing symlinks: libnetapi-devel-32bit Mesa-libGL-devel-32bit!
* There is no OpenCL 32-bit package at all (ocl-icd-devel-32bit and libOpenCL1-32bit are both missing). And for 64-bit one needs both opencl-headers and ocl-icd-devel. OpenCL is all around weird.
* The following packages don't seem to be necessary: bison-32bit freeglut-devel* giflib-devel* bopenssl-devel* xz-devel*
* Other missing libraries. If someone figures out a clean way to script these or has good documentation I can link to: FAudio-devel prelink (not a lib) vkd3d-devel
I'm hoping this can help Wine developers get started on openSUSE.
On Thu, 28 May 2020 05:52:38 +0200 (CEST) Francois Gouget fgouget@free.fr wrote:
Right, I used 'empty' in a somewhat loose sense. registry.i586.bin is small (<= 25kB instead of > 200kB) and running strings on it shows all plugins are blacklisted:
Both my files are over 900kB, and nothing is blacklisted: $ strings .cache/gstreamer-1.0/registry.i586.bin | head -n12 1.3.0 encoding various encoding-related elements /usr/lib/gstreamer-1.0/libgstencoding.so 1.12.5 LGPL gst-plugins-base openSUSE GStreamer-plugins-base package http://download.opensuse.org 2018-03-28 GstElementFactory encodebin
$ strings .cache/gstreamer-1.0/registry.x86_64.bin | head -n12 1.3.0 encoding various encoding-related elements /usr/lib64/gstreamer-1.0/libgstencoding.so 1.12.5 LGPL gst-plugins-base openSUSE GStreamer-plugins-base package http://download.opensuse.org 2018-03-28 GstElementFactory encodebin
Here are some things I found while writing / testing it on openSUSE 15.1:
- MinGW does not seem to be readily available. Compiling Wine without MinGW is likely not to get tested much in the future so that's concerning.
MinGW packages are available in the windows:mingw repository on the OBS. I've been able to build Wine with MinGW support locally and I can tell you what MinGW packages I have installed, but I don't know how many of those are actually needed--my method was to keep installing stuff until configure stopped complaining.
mingw32-cross-gcc-8.2.0-lp150.13.10.x86_64 mingw32-cross-binutils-2.32-lp150.5.1.x86_64 mingw32-filesystem-20190529-lp150.1.1.noarch mingw32-cross-cpp-8.2.0-lp150.13.10.x86_64 mingw32-cross-breakpad-tools-20140827-lp150.6.1.x86_64 mingw32-gcc-8.2.0-lp150.5.13.noarch mingw32-runtime-6.0.0-lp150.1.11.noarch mingw32-libmpc3-1.0.2-lp150.5.34.noarch mingw32-cpp-8.2.0-lp150.5.13.noarch mingw32-libmpfr4-3.1.2-lp150.5.34.noarch mingw32-headers-6.0.0-lp150.1.6.noarch mingw32-winpthreads-devel-6.0.0-lp150.1.9.noarch mingw32-libz-1.2.11-lp150.2.3.noarch mingw32-libwinpthread1-6.0.0-lp150.1.9.noarch mingw32-libgmp10-6.1.1-lp150.2.35.noarch mingw32-libgcc_s_sjlj1-8.2.0-lp150.5.13.noarch mingw32-binutils-2.32-lp150.2.3.noarch mingw64-cross-gcc-8.2.0-lp150.5.8.x86_64 mingw64-cross-binutils-2.32-lp150.3.1.x86_64 mingw64-filesystem-20170720-lp150.4.1.noarch mingw64-cross-cpp-8.2.0-lp150.5.8.x86_64 mingw64-cross-breakpad-tools-20140827-lp150.8.1.x86_64 mingw64-gcc-8.2.0-lp150.2.8.noarch mingw64-cpp-8.2.0-lp150.2.8.noarch mingw64-runtime-6.0.0-lp150.1.12.noarch mingw64-libmpc3-1.0.2-lp150.5.26.noarch mingw64-libmpfr4-3.1.4-lp150.1.26.noarch mingw64-headers-6.0.0-lp150.1.1.noarch mingw64-zlib1-1.2.11-lp150.1.4.noarch mingw64-winpthreads-devel-6.0.0-lp150.1.10.noarch mingw64-libwinpthread1-6.0.0-lp150.1.10.noarch mingw64-libgmp10-6.1.1-lp150.2.26.noarch mingw64-libgcc_s_seh1-8.2.0-lp150.2.8.noarch mingw64-binutils-2.32-lp150.2.1.noarch
- A number of -devel-32bit packages don't depend on package that contains the libraries, resulting in unusable dead links. The culprits are: fontconfig-devel-32bit libgphoto2-devel-32bit libpulse-devel-32bit libv4l-devel-32bit openal-soft-devel-32bit sane-backends-devel-32bit vulkan-devel-32bit
The libraries for all of those should be pulled in as dependencies by installing the wine-32bit package from the Emulators:Wine repository (which is itself pulled in as a dependency by the wine package), though it looks like sane isn't. I'm not sure why; the sane-backends-32bit package is in the main repository.
- There are a couple other missing -devel-32bit packages that the script works around by creating the missing symlinks: libnetapi-devel-32bit Mesa-libGL-devel-32bit!
I don't have either of those packages installed, and don't have the 64 bit libnetapi-devel package either, and configure has never complained about either one. I do have the 32 and 64 bit libraries installed for both.
- There is no OpenCL 32-bit package at all (ocl-icd-devel-32bit and libOpenCL1-32bit are both missing). And for 64-bit one needs both opencl-headers and ocl-icd-devel. OpenCL is all around weird.
Yes, it is weird. But I don't have any use for it myself, so I've never really pursued it beyond getting the packages needed to satisfy configure.
- The following packages don't seem to be necessary: bison-32bit freeglut-devel* giflib-devel* bopenssl-devel* xz-devel*
Hm, some of those may have been carried over from old howtos. I'll have to take a closer look whenever I get around to updating the wiki.
- Other missing libraries. If someone figures out a clean way to script these or has good documentation I can link to: FAudio-devel
FAudio-devel and FAudio-devel-32bit are both in the Emulators:Wine repository.
prelink (not a lib)
I don't have that installed at all. I vaguely remember it used to be required, but it hasn't been needed in years.
vkd3d-devel
I wound up building that myself; there are also a couple of other personal OBS projects that have it. https://build.opensuse.org/package/show/home:dimesio/vkd3d
In general, if something is not in the main or update repository, search the OBS, as there's a pretty good chance someone has already built it.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean
On Thu, 28 May 2020, Rosanne DiMesio wrote:
On Thu, 28 May 2020 05:52:38 +0200 (CEST) Francois Gouget fgouget@free.fr wrote:
Right, I used 'empty' in a somewhat loose sense. registry.i586.bin is small (<= 25kB instead of > 200kB) and running strings on it shows all plugins are blacklisted:
Both my files are over 900kB, and nothing is blacklisted:
It turns out Wine has a workaround which allows it to not trigger this bug: https://www.winehq.org/pipermail/wine-devel/2020-May/166969.html
(but once the registry file is broken, Wine is impacted too)
Here are some things I found while writing / testing it on openSUSE 15.1:
- MinGW does not seem to be readily available. Compiling Wine without MinGW is likely not to get tested much in the future so that's concerning.
MinGW packages are available in the windows:mingw repository on the OBS. I've been able to build Wine with MinGW support locally and I can tell you what MinGW packages I have installed, but I don't know how many of those are actually needed--my method was to keep installing stuff until configure stopped complaining.
Excellent. I have updated the script to add support for adding OBS repositories. It now uses the Emulators:Wine, windows:mingw:win32, windows:mingw:win64 and home:dimesio OBS 'projects' to provide FAudio, MinGW win32, MinGW win64 and vkd3d respectively.
https://github.com/fgouget/wt-daily/blob/master/wt-install-dev#L722
I hope this can make it easy for openSUSE developers to get their system set up to work on Wine.
- A number of -devel-32bit packages don't depend on package that contains the libraries, resulting in unusable dead links. The culprits are: fontconfig-devel-32bit libgphoto2-devel-32bit libpulse-devel-32bit libv4l-devel-32bit openal-soft-devel-32bit sane-backends-devel-32bit vulkan-devel-32bit
The libraries for all of those should be pulled in as dependencies by installing the wine-32bit package from the Emulators:Wine repository
There is no need for Emulators:Wine here since this is all in the main repository anyway. It's just that fontconfig-devel-32bit should depend on fontconfig-devel but does not. vkd3d-devel-32bit has the same problem by the way: it should depend on libvkd3d1-32bit but does not (hint).
- There are a couple other missing -devel-32bit packages that the script works around by creating the missing symlinks: libnetapi-devel-32bit Mesa-libGL-devel-32bit!
I don't have either of those packages installed, and don't have the 64 bit libnetapi-devel package either, and configure has never complained about either one. I do have the 32 and 64 bit libraries installed for both.
Wine's configure does not complain about libnetapi since it's a relatively minor dependency. As for Mesa-libGL-devel-32bit I suspect you have Mesa-libGL1-32bit installed and your page documents creating the needed libGL.so symlink so that's why Wine does not complain about it.
prelink (not a lib)I don't have that installed at all. I vaguely remember it used to be required, but it hasn't been needed in years.
I'm not sure it's no longer needed. I believe it's more of a case where it's only needed for a few applications so one can get by without it. But maybe I'm wrong.
MinGW packages are available in the windows:mingw repository on the OBS. I've been able to build Wine with MinGW support locally and I can tell you what MinGW packages I have installed, but I don't know how many of those are actually needed--my method was to keep installing stuff until configure stopped complaining.
Excellent. I have updated the script to add support for adding OBS repositories. It now uses the Emulators:Wine, windows:mingw:win32, windows:mingw:win64 and home:dimesio OBS 'projects' to provide FAudio, MinGW win32, MinGW win64 and vkd3d respectively.
https://github.com/fgouget/wt-daily/blob/master/wt-install-dev#L722
I hope this can make it easy for openSUSE developers to get their system set up to work on Wine.
- A number of -devel-32bit packages don't depend on package that contains the libraries, resulting in unusable dead links. The culprits are: fontconfig-devel-32bit libgphoto2-devel-32bit libpulse-devel-32bit libv4l-devel-32bit openal-soft-devel-32bit sane-backends-devel-32bit vulkan-devel-32bit
The libraries for all of those should be pulled in as dependencies by installing the wine-32bit package from the Emulators:Wine repository
There is no need for Emulators:Wine here since this is all in the main repository anyway. It's just that fontconfig-devel-32bit should depend on fontconfig-devel but does not. vkd3d-devel-32bit has the same problem by the way: it should depend on libvkd3d1-32bit but does not (hint).
Btw, in the Emulators:Wine I have a special sub-package "wine-32bit-build-deps" that pulls all the build deps in.
I have not checked it lately though, and it might need updates.
I am working on your 15.1 bugs too.
Ciao, Marcus
On Sat, 30 May 2020, Marcus Meissner wrote: [...]
Btw, in the Emulators:Wine I have a special sub-package "wine-32bit-build-deps" that pulls all the build deps in.
I have not checked it lately though, and it might need updates.
Interestingly it has some of the same extra packages as the wiki's openSUSE page: freeglut-devel-32bit libglvnd-devel-32bit
It's also missing some of the lesser dependencies: libnetapi, ODBC, libusb but also libunwind which seems important for 64-bit.
It also does not seem to work around the missing dependencies in the -devel-32bit packages, though it looks like that will soon be a thing of the past.
More importantly it's missing MinGW and vkd3d which makes sense since they are not present in the mainline packages or on the Emulators:Wine project.
So there are three options for openSUSE Wine developers: * Manually add Emulators:Wine and install wine-32bit-build-deps. Provides most dependencies.
zypper addrepo https://download.opensuse.org/repositories/Emulators:Wine/<you-distro-name-here>/Emulators:Wine.repo zypper refresh zypper install wine-32bit-build-deps
* The wiki's openSUSE page instructions. https://wiki.winehq.org/OpenSUSE#Building_32_bit_Wine Lots of manual work and also provides most dependencies.
* wt-install-dev My favorite obviously ;-), requires essentially no manual work and provides all the dependencies... at least today and on openSUSE Leap 15.1. May not work on Tumbleweed.
When I say simple I really mean it. This one liner should be all you need: wget https://raw.githubusercontent.com/fgouget/wt-daily/master/wt-install-dev && sh wt-install-dev --yes
For reference, here are the commands it runs on openSUSE Leap 15.1. Maybe that would be a good basis to update the wiki instructions? (or maybe they should be simplified to leverage Emulators:Wine or wt-install-dev more?)
zypper addrepo https://download.opensuse.org/repositories/Emulators:Wine/openSUSE_Leap_15.1... zypper addrepo https://download.opensuse.org/repositories/windows:mingw:win32/openSUSE_Leap... zypper addrepo https://download.opensuse.org/repositories/windows:mingw:win64/openSUSE_Leap... zypper addrepo https://download.opensuse.org/repositories/home:dimesio/openSUSE_Leap_15.1/h... zypper refresh zypper install FAudio-devel FAudio-devel-32bit Mesa-libGL-devel \ Mesa-libGL1 Mesa-libGL1-32bit alsa-devel alsa-devel-32bit autoconf \ bison capi4linux-devel capi4linux-devel-32bit cups-devel \ cups-devel-32bit dbus-1-devel dbus-1-devel-32bit flex fontconfig fontconfig-32bit fontconfig-devel fontconfig-devel-32bit \ freetype2-devel freetype2-devel-32bit gcc gcc-32bit git glib2-devel glib2-devel-32bit glibc-devel glibc-devel-32bit glu-devel \ glu-devel-32bit gstreamer-devel gstreamer-plugins-base-devel \ gstreamer-plugins-base-devel-32bit krb5-devel krb5-devel-32bit \ libFAudio0 libFAudio0-32bit libOSMesa-devel libOSMesa-devel-32bit \ libOpenCL1 libSDL2-devel libSDL2-devel-32bit libX11-devel \ libX11-devel-32bit libXcomposite-devel libXcomposite-devel-32bit \ libXcursor-devel libXcursor-devel-32bit libXext-devel \ libXext-devel-32bit libXfixes-devel libXfixes-devel-32bit libXi-devel \ libXi-devel-32bit libXinerama-devel libXinerama-devel-32bit \ libXrandr-devel libXrandr-devel-32bit libXrender-devel \ libXrender-devel-32bit libXxf86vm-devel libXxf86vm-devel-32bit \ libcom_err-devel libcom_err-devel-32bit libexif-devel \ libexif-devel-32bit libgnutls-devel libgnutls-devel-32bit libgphoto2-6 \ libgphoto2-6-32bit libgphoto2-devel libgphoto2-devel-32bit \ libgsm-devel libgsm-devel-32bit libjpeg8-devel libjpeg8-devel-32bit \ liblcms2-devel liblcms2-devel-32bit libnetapi-devel libnetapi0 \ libnetapi0-32bit libopenal1 libopenal1-32bit libpcap-devel \ libpcap-devel-32bit libpng16-compat-devel libpng16-compat-devel-32bit \ libpulse-devel libpulse-devel-32bit libpulse0 libpulse0-32bit \ libtiff-devel libtiff-devel-32bit libudev-devel libudev-devel-32bit \ libunwind-devel libusb-1_0-devel libusb-1_0-devel-32bit libv4l-devel \ libv4l-devel-32bit libv4l2-0 libv4l2-0-32bit libvkd3d1 libvkd3d1-32bit \ libvulkan1 libvulkan1-32bit libxml2-devel libxml2-devel-32bit libxslt-devel \ libxslt-devel-32bit make mingw32-cross-gcc mingw64-cross-gcc \ mpg123-devel mpg123-devel-32bit ncurses-devel ncurses-devel-32bit \ ocl-icd-devel openal-soft-devel openal-soft-devel-32bit opencl-headers \ openldap2-devel openldap2-devel-32bit python3 sane-backends \ sane-backends-32bit sane-backends-devel sane-backends-devel-32bit \ unixODBC unixODBC-32bit unixODBC-devel unzip vkd3d-devel \ vkd3d-devel-32bit vulkan-devel vulkan-devel-32bit wget zlib-devel \ zlib-devel-32bit ln -s -f libgstbase-1.0.so.0 /usr/lib/libgstbase-1.0.so ln -s -f libgstreamer-1.0.so.0 /usr/lib/libgstreamer-1.0.so ln -s -f libnetapi.so.0 /usr/lib/libnetapi.so ln -s -f libGL.so.1 /usr/lib/libGL.so
I am working on your 15.1 bugs too.
Yep. Saw that. That's great. And the good news is I think I'm done finding more things for you to fix ;-)
On Sat, 30 May 2020 20:42:50 +0200 (CEST) Francois Gouget fgouget@free.fr wrote:
For reference, here are the commands it runs on openSUSE Leap 15.1. Maybe that would be a good basis to update the wiki instructions? (or maybe they should be simplified to leverage Emulators:Wine or wt-install-dev more?)
That will be a big help in updating the wiki. I still want to document all the steps, but I will point to your script as an easier way to do it all.
On Sat, 30 May 2020, Rosanne DiMesio wrote:
On Sat, 30 May 2020 20:42:50 +0200 (CEST) Francois Gouget fgouget@free.fr wrote:
For reference, here are the commands it runs on openSUSE Leap 15.1. Maybe that would be a good basis to update the wiki instructions? (or maybe they should be simplified to leverage Emulators:Wine or wt-install-dev more?)
That will be a big help in updating the wiki. I still want to document all the steps, but I will point to your script as an easier way to do it all.
I added a --cmd-log SCRIPT option that saves the commands being run in the specified SCRIPT file. The script can then be run to set up another (identical) system directly [1]. Mostly it's an easy way to get at all the relevant commands and copy/paste them wherever.
Also wt-install-dev now also supports openSUSE Tumbleweed.
[1] Note that a script generated on openSUSE Tumbleweed will obviously not work on openSUSE Leap. But also the workaround commands may not be complete if wt-install-dev was run in --dry-run mode, or if a previous run of wt-install-dev had already set up some of the workarounds. So the generated script only works on really *identical* systems (unlike wt-install-dev itself). But it's still good documentation.
I'll use this thread to mention one last strange thing I noticed in the openSUSE packages: the case of unixODBC.
There's three packages: unixODBC-devel unixODBC unixODBC-32bit
So one may think that it's missing the -devel-32bit package. But not at all!
unixODBC-devel only contains the headers. The .so symlinks are in the unixODBC and unixODBC-32bit packages. So as a result there is no need for a -devel-32bit package.
Very non standard but it works (so no bug report).
-
Francois Gouget -
Marcus Meissner -
Marcus Meissner -
Paul Gofman -
Rosanne DiMesio -
Zebediah Figura