gstreamer integration in Windows app - DLL dependencies on different PCs

[David Ing]

You might try twiddling the environment variables from my prior post.  The
variables named like GSTREAMER_ROOT_... and GSTREAMER_1_0_ROOT_... are how
gstreamer tries to find its home.  You can use GST_PLUGIN_PATH to point to
whatever folder contains the plugins.

It is also possible to use Process Monitor to see which DLLs are failing to
load.  https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

On Tue, Mar 22, 2022 at 12:01 PM MK <pikim at web.de> wrote:

> Sorry, I forgot to mention that I'm already using both current MSVC 32-bit
> packages. They're installed at the default location under C:\gstreamer. To
> deploy 'my' DLL, I threw the necessary gstreamer DLLs into the same folder
> and copied the whole parent directory to another PC.
>
>
> Am 22.03.22 um 16:26 schrieb David Ing:
>
> I don't know what might be causing this, but you might save yourself some
> time by skipping the build and using the MSVC installers to get the build
> artifacts.  (The MSVC is less buggy than the MinGW.)
>
> What I do is I install the "runtime installer" and "development
> installer", then I copy the components from C:\gstreamer (or wherever) into
> a portable little "package" that my C++ code can reference.
>
> After you run the installers, check your environment for variable names
> that begin with GST, and your path for anything like "C:\gstreamer\...",
> and purge all of that.
>
> BTW, my C++ application does a bit of environmental housekeeping just
> before I initialize gstreamer (with gst_init).  I'm not sure if this stuff
> is necessary but it works for us.
>
>             // This is where the plugins live.            boost::filesystem::path pluginFolder = assemblyFolder / "plugins";            // WARNING: setting an environment variable is only safe at the beginning of the program (before any            // other threads have been spun up).  We do this to maintain strict control over the components that            // we are using.            const char* priorGstPluginPath = g_getenv("GST_PLUGIN_PATH");            std::string gstPluginPath = string::unwiden(pluginFolder.string());            if (priorGstPluginPath && (0 != priorGstPluginPath[0]))            {                gstPluginPath = gstPluginPath + PATHS_SEP_STR + priorGstPluginPath;            }            g_unsetenv("GST_PLUGIN_SYSTEM_PATH_1_0");            g_unsetenv("GST_PLUGIN_SYSTEM_PATH");            g_unsetenv("GST_PLUGIN_PATH_1_0");#if ARCH_32_BIT            g_unsetenv("GSTREAMER_ROOT_X86");
>             g_unsetenv("GSTREAMER_ROOT_MSVC_X86");            g_setenv("GSTREAMER_1_0_ROOT_X86", string::unwiden(assemblyFolder.string()).c_str(), true);            g_setenv("GSTREAMER_1_0_ROOT_MSVC_X86", string::unwiden(assemblyFolder.string()).c_str(), true);#elif ARCH_64_BIT
>             g_unsetenv("GSTREAMER_ROOT_X86_64");            g_unsetenv("GSTREAMER_ROOT_MSVC_X86_64");            g_setenv("GSTREAMER_1_0_ROOT_X86_64", string::unwiden(assemblyFolder.string()).c_str(), true);            g_setenv("GSTREAMER_1_0_ROOT_MSVC_X86_64", string::unwiden(assemblyFolder.string()).c_str(), true);#else  #error "Unknown architecture (32-bit vs. 64-bit)"#endif            g_setenv("GST_PLUGIN_PATH", gstPluginPath.c_str(), true);#if BOOST_OS_WINDOWS            // The nuget package provides some modules that are needed to enable some fancy network encryption stuff, but
>             // I have only seen it available on Windows.  Perhaps it is not required on Linux.  We only need it on Windows            // because it enables a feature that enables WebRTC in our Windows client aplications.            boost::filesystem::path gioModuleFolder = assemblyFolder / "gio_modules";            std::string gioModuleFolderString = string::unwiden(gioModuleFolder.string());            g_setenv("GIO_MODULE_DIR", gioModuleFolderString.c_str(), true);#endif
>
>
> On Tue, Mar 22, 2022 at 4:52 AM MK via gstreamer-devel <
> gstreamer-devel at lists.freedesktop.org> wrote:
>
>> Hello,
>>
>> I've written a DLL plugin for a 3rd party application which initially
>> only used libjpeg for motion JPEG support. I used a VisualStudio (2017)
>> template which the 3rd party supplier provides as starting point. That
>> worked fine.
>>
>> To be able to support other stream formats, I switched to gstreamer
>> instead of libjpeg. I can build the plugin and it works fine on the PC
>> where it was compiled (let's call it PC1). When I copy all the files to
>> another PC (PC2), the 3rd party application fails to load the DLL,
>> because of some missing DLL dependencies. When I compile the project on
>> PC2, it works well on PC2. But the version from PC2 fails on PC1.
>>
>> I checked the dependencies with 'Dependencies' and noticed that on PC1
>> the missing DLLs differ from the missing DLLs on PC2. But even the
>> required DLLs differ from PC1 to PC2.
>>
>> Does anyone have an idea what could cause this behavior?
>>
>> Best regards,
>> Michael
>>
>> PS: both versions do not run on PC3.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20220322/01d2d747/attachment.htm>