[gst-devel] Segfault in CVS gst-register

[Brett Kosinski]

> > As you can see, it appears to be a problem with the gstelements plugin,
> > although I can't for the life of me, figure out what it is.  Thoughts?  I
> > had this problem with 0.6.1 as well, but disabling the fakesink (I think)
> > feature fixed the problem.
> >
> > Note, this is with a CVS version of gstreamer and gst-plugins (checked out
> > a couple nights ago).
>
> You're adding the plugin path twice (by specifying the command line
> option).  See http://bugzilla.gnome.org/show_bug.cgi?id=112745

Well, first off, yes, that's the problem, but it's slightly more complex
than that.  The problem is that gst-register should NOT automatically add
$(INST_LIBDIR) to the plugin path on startup if GST_PLUGIN_PATH is set or
--gst-plugin-path is used.

You see, in my system, I use stow to manage my custom packages.
GStreamer is installed to /usr/local/packages/gstreamer and gst-plugins is
installed to /usr/local/packages/gst-plugins.  I then use stow to install
the two to /usr/local/.  However, gst-register automatically adds
"/usr/local/packages/gstreamer/lib/gstreamer-0.7" to the plugin path
without my permission, and so just running gst-register by itself will
only detect the default plugin set (since the full set of plugins is, in
actuality, available at /usr/local/lib/gstreamer-0.7).

Of course, the workaround is to add
"/usr/local/packages/gst-plugins/lib/gstreamer-0.7" to the plugin path,
however I consider this incorrect, since the behaviour that I (and most
people, I think) would assume is that any plugin path set (either through
the GST_PLUGIN_PATH variable or with the --gst-plugin-path parameter)
should overwrite any "default" settings in gst-register itself (think how
the java CLASSPATH, or even the Unix PATH variable, is used).  This way, I
can set the plugin path to "/usr/local/lib/gstreamer-0.7" and have it do
the right thing for my setup.

Anyway, this is just MHO.  Things are working now (thanks for the tip, BTW),
so I'm happy. :)

Brett.