Regression in GStreamer gst-plugin-scanner so it uses the wrong PATH to search for DLLs from 1.22.5 to 1.24.1

[46cv8]

Description / Steps to reproduce the issue

Under msys2 using the ucrt64 and mingw64 variants (possibly others but I haven't tested) the path that gst-plugin-scanner is passing to libpython.dll is causing it to scan in the wrong path for the python dlls (see below for more details). Just to be clear this works fine under 1.22.5 and even 1.22.9 if memory serves me correctly (but I don't have a snapshot I can test against for 1.22.9).

1. install msys2 (https://stackoverflow.com/questions/37460073/msys-vs-mingw-internal-environment-variables)
2. follow steps at https://pygobject.readthedocs.io/en/latest/getting_started.html
3. open ucrt64 shell
4. pacman -Suy pacman -S mingw-w64-ucrt-x86_64-gtk4 mingw-w64-ucrt-x86_64-python3 mingw-w64-ucrt-x86_64-python3-pip mingw-w64-ucrt-x86_64-python3-gobject mingw-w64-ucrt-x86_64-python-wheel
5. pacman -S mingw-w64-ucrt-x86_64-gstreamer mingw-w64-ucrt-x86_64-gst-devtools mingw-w64-ucrt-x86_64-gst-plugins-base mingw-w64-ucrt-x86_64-gst-plugin-gtk mingw-w64-ucrt-x86_64-gst-plugins-bad mingw-w64-ucrt-x86_64-gst-plugins-bad-libs mingw-w64-ucrt-x86_64-gst-plugins-good mingw-w64-ucrt-x86_64-gst-plugins-ugly mingw-w64-ucrt-x86_64-gst-python
6. building libgstpython.dll (https://gstreamer.freedesktop.org/documentation/installing/building-from-source-using-meson.html?gi-language=python)
7. pacman -S git mingw-w64-ucrt-x86_64-meson-python mingw-w64-ucrt-x86_64-cc mingw-w64-ucrt-x86_64-meson mingw-w64-ucrt-x86_64-ninja mingw-w64-ucrt-x86_64-pkg-config mingw-w64-ucrt-x86_64-pygobject-devel mingw-w64-ucrt-x86_64-python
8. git clone https://gitlab.freedesktop.org/gstreamer/gstreamer.git
9. cd gstreamer
10. git checkout 1.24.1
11. cd subprojects/gst-python/
12. meson build
13. cd build
14. ninja
15. cp plugin/libgstpython.dll /ucrt64/lib/gstreamer-1.0/libgstpython.dll
16. gst-inspect-1.0.exe > /dev/null

    ** (gst-plugin-scanner.exe:1708): CRITICAL **: 10:06:16.091: pygobject initialization failed: could not import gobje
    ct (error was: ImportError('DLL load failed while importing _gi: The specified module could not be found.'))

Investigation done:

• Check "under observed behavior" for more details, but I think I was able to successfully get the 1.22.5 libgstpython.dll working under 1.24.1, until the plugin cache detected a change and attempted to rescan the plugin and failed.
• I think mingw64 is more mainstream than ucrt64 so I repeat the above build steps using mingw64 and I ran into the exact same issue, so it applies to both variants.
• I tried incrementally updating pacman packages between my working snapshot that was running 1.22.5 and 1.24.1 but pacman doesn't support partial package updates so I was unable to isolate precisely which package or which version change broke things.... I am happy to try use historical mingw64.db pacman database files to attempt to bisect every possible package state between 1.22.5 and 1.24.1 gstreamer to see precisely which package update broke it. But I don't know of any place I can get historical mingw64.db files to install a consistent state of packages at various snapshots in time https://repo.msys2.org/mingw/mingw64/ has only the latest mingw64.db, even though it has historical packages going back 3 years, without knowing a consistent working package state at different points in time it makes performing this kind of analysis very difficult. Is there a backup of historical mingw64.db package databases anywhere? archive.org doesn't seem to have any either.

I posted an issue over at freedesktop for the gstreamer guys but I'm not sure this is a gstreamer issue, it seems like it may be more of a msys2 issue as it is searching the windows path, when it should be searching /ucrt64/bin or /mingw64/bin... https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3434

Expected behavior

On my working 1.22.5 environment gst-plugin-scanner. first scans in the following folder to look for the dll and fails to find it.

C:\msys64\ucrt64\lib\python3.11\site-packages\gi\libgirepository-1.0-1.dll

Then finds it in the second place it looks.

C:\msys64\ucrt64\bin\libgirepository-1.0-1.dll

Actual behavior

On my newly installed 1.24.1 environment gst-plugin-scanner scans in three locations all of which don't have the required dlls.

  C:\msys64\ucrt64\lib\python3.11\site-packages\gi\libgirepository-1.0-1.dll
  C:\msys64\ucrt64\libexec\gstreamer-1.0\libgirepository-1.0-1.dll
  C:\Windows\System32\libgirepository-1.0-1.dll

I had originally thought libgstpython changes were the source of the issue, but I don't think they are. Doing some careful file copying to make sure the gstreamer plugin cache never detected a change to libgstpython.dll. I was actually able to get gstreamer 1.24.1 to use the 1.22.5 libgstpython.dll and it didn't run into the issue and was even able to run my python gstreamer plugin fine. I then invalidated the plugin cache, and immediately (even though libgstpython.dll was the same one it had been using successfully) gst-plugin-scanner started to throw errors because it thought the dll's used by various python site-package libraries were missing, because it is searching in the wrong path.

Verification

• [X] I have verified that my MSYS2 is up-to-date before submitting the report (see https://www.msys2.org/docs/updating/)

Windows Version

MINGW64_NT-10.0-19044

Are you willing to submit a PR?

No response

[46cv8]

Soo my original analysis was slightly flawed, the bug is real, but the reason it works under 1.22.5 is because gst-plugin-scanner.exe is never called under 1.22.5 it is however called in 1.24.1. Renaming gst-plugin-scanner.exe to gst-plugin-scanner.exe.bak so it can't be called seems to be sufficient to get things working again. I suspect gst-plugin-scanner may have always been using the wrong path for python module dlls, the only reason it wasn't an issue until now is because it was not actually being called for 1.22.5 and earlier.

So the workaround is just to delete it for now. But please be aware it is indeed broken and searching the wrong path and needs to be fixed.

[lazka]

Does export PYTHONLEGACYWINDOWSDLLLOADING=1 help?

[46cv8]

Sorry for my late reply! Yes! This fixes it! I will add this to my application. Thanks so much :)

[lazka]

Thanks. Then this is likely related to https://github.com/msys2-contrib/cpython-mingw/issues/161