[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mingw-cross-env-list] Static GStreamer plugins aren't loaded
From: |
Mark Brand |
Subject: |
Re: [Mingw-cross-env-list] Static GStreamer plugins aren't loaded |
Date: |
Wed, 05 Jun 2013 20:24:02 +0200 |
User-agent: |
KMail/4.10.3 (Linux/3.8.0-23-generic; KDE/4.10.3; x86_64; ; ) |
> OK, I finally had some success with this. GStreamer is perfectly
> capable of being statically linked with an application, including its
> plugins. However, for that to be useful, the application needs to
> explicitly link against every static plugin it needs. In my setup for
> example, to link-in the coreelements plugin, I have to add this to the
> linker flags:
>
> -L/home/realnc/opt/mxe/usr/i686-pc-mingw32/lib/gstreamer-0.10
>
> and then manually link against the plugin:
>
> -lcoreelements
>
> And then also manually declare and register every needed plugin in the
> code of the application:
>
> // Must be done at global file scope, since this results in a function
> // prototype being declared.
> GST_PLUGIN_STATIC_DECLARE(coreelements);
>
> // Call the init function of the plugin.
> GST_PLUGIN_STATIC_REGISTER(coreelements);
>
Nice summary. That's reminds me a lot of how static plugins in Qt are used,
except that qmake in Qt 5 generates the linking, declaring and initialization
code. All the programmer has to do is add the QTPLUGINS directive to the .pro
file with a list of plugins to include.
> There is no automation for this (pkg-config will not help with getting
> the plugin paths and libraries to link against). I don't know if MXE
> could possibly help with this. Like getting the plugin path would be
> helpful so people won't have to hard-code the path into their build
> system. Is there a variable exported that least gives build systems a
> chance to get to the "lib" directory?
How about using pkg-config --variable=prefix to get the prefix of the gstreamer
installation, and then using a relative path from there to the plugin path?
Mark