GNOME Bugzilla – Bug 784337
win32 relocatability behaves unexpectedly when the application path contains a "bin" folder
Last modified: 2017-09-16 13:32:40 UTC
Gstreamer doesnt work correctly when the application path contains a folder named: "bin". It doesn't matter where the bin folder is in the application path e.g.: "C:\my_path\is\here\bin\app.exe" or "C:\bin\my_path\is\here\app.exe" When there is a "bin" folder the application will not work anymore. You could set the "GST_PLUGIN_PATH", which is of course a workaround only. And doesn't work in further code calls: When I did later a call to `gst_discoverer_discover_uri`, the application blocked for unknown reason (when I removed my app from the "bin" subfolder everything worked again) GStreamer should always search first, relative to the gstreamer DLL location For example: Module path: "C:\my_path\is\here\bin\libgstreamer-1.0-0.dll" First try this plugin path: "C:\my_path\is\here\bin\lib\gstreamer-1.0\" The gstreamer applications like gst-discoverer-1.0.exe and gst-launch-1.0.exe should be portable applications, but in fact they aren't because of this limitation... This is an absolute intuitive behavior, which needs to be fixed. PS: I don't know whether this is a windows only bug.
This is Windows-only and behaviour caused by g_win32_get_package_installation_directory_of_module(). It considers the installation directory the one that is the parent directory of the DLL after skipping all "bin" and "lib" directories. Adding just ../lib/gstreamer-1.0 relative to the parent directory as another, additional search path if it is different from the above and the above is not found could be done. It is important to keep backwards compatibility. Also this is not really a "major" bug but a feature request. It is all working as documented and you are using a custom directory structure, so first of all you'll have to work around that and probably also run into similar problems with other libraries (e.g. GIO not finding the TLS module).
This broken behavior was actually introduced in bug 733934. Discussion on reverting to the documented (and desired) behavior is in bug 739835. While there are use cases where the current (undocumented) behavior might be desirable it breaks the documented behavior which is expected by a lot of software and should therefore be restored. As this case highlights even "DLLs that are of the dynamically loaded module or plugin variety are often located in more private locations deeper down in the tree" (to cite the documentation) seem to fail because of the unexpected behavior of g_win32_get_package_installation_directory_of_module that was introduced in the linked bug (which was supposed to fix specifically this case).
*** This bug has been marked as a duplicate of bug 739835 ***