gstreamer integration in Windows app - DLL dependencies on different PCs
MK
pikim at web.de
Tue Mar 22 19:01:29 UTC 2022
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/bb691a66/attachment-0001.htm>
More information about the gstreamer-devel
mailing list