[gst-devel] please help on my own base element

[Tim-Philipp Müller]

On Mon, 2011-01-31 at 15:43 -0800, kevin kelly wrote:

> I am trying to generate  my own base element called GstMyDecoder, which is
> very similar to GstbaseTransform, so that I can derive other elements from
> this base element. 
> 
> I compiled this GstMyDecoder and generated .so file without any errors. This
> .so file and header file gstmydecoder.h was copied to /usr/lib/gstream-0.10/
> and /usr/include/gstreamer-0.10/gst accordingly. 
> 
> I also derived GstMyChildDecoder from this GstMyDecoder element. The .so
> file was also compiled without any errors and was copied to
> /usr/lib/gstream-0.10/
> 
> But when I tried to use "gst-inspect childdecoder", I got following error
> message:
> 
> GStreamer-WARNING **: Failed to load plugin
> '/usr/lib/gstreamer-0.10/libgstmychilddecoder.so':
> /usr/lib/gstreamer-0.10/libgstmychilddecoder.so: undefined symbol:
> gst_my_decoder_get_type
> 
> would you please help me to find what's wrong and how to solve this issue?
> Is there any special procedure to compile this base element?

There are two types of .so files in a GStreamer context:

(a) libraries which provide (export) API such as functions to external
users; these are usually installed into /usr/lib/ (e.g.
libgst*-0.10.so), with headers going somewhere into /usr/include. Users
of such libraries usually link to the libraries needed when building the
application/library dependent on it.

(b) plugins, which are usually found and loaded at runtime and do not
export any public symbols (other than an entry point with a plugin
description and the plugin init function).

If you want to make a new base class available, you need to create a
library, not a plugin (please don't name it libgst* though, but libmy*).

Having said that, there is no reason why you can't include such a base
class in your plugin if only elements in this plugin depend on it (see
e.g. the audioparsers plugin in -bad which contains an internal copy of
a GstBaseParse).

Cheers
 -Tim