[gst-devel] a few lib issues

[Thomas Vander Stichele]

Hi everyone,

so we have a few lib issues which I would like to solve on a relatively 
short term.

a) libgstcontrol.so

This is currently a plug-in as well as a library.  Other plug-ins load it 
as a supporting lib in the plug-in code so they can use the functions.  
Linking of plug-ins using it succeeds obviously without adding 
-lgstcontrol since they dlopen the lib themselves.

Some apps also need to link to it explicitly.  Consider gst-player.
gst-player uses an internal lib, libplay, which contains the gstcontrol
functions it needs.  Linking of libplay.so succeeds without problems, just 
like a plug-in would be able to be linked.

However, at the moment you link the app *without* gstcontrol as a lib, 
linking fails because of missing symbols.  There is no way around this 
that I know of.

If you link the app with -lgstcontrol, the final linking works (because 
the right lib location is on the link line), but execution of the 
resulting binary can fail (because it hasn't been added with -rpath, but 
that's something we won't discuss here).

Ok, some people seem to be saying that there is a way to make this last 
problem go away, but both steveb and I couldn't figure out how.  I also 
think that this only worked because we all compile stuff for gstreamer all 
with the same prefix, which makes this work by accident.  I could detail 
more why this is but it's not relevant right now.  If anyone thinks this 
can be done, *please* explain me how or provide a sample that does it 
and succeeds with the core being configured for a different prefix than 
the player.

Personally, I think it can't be done, and we have to figure some other 
way.
Here's a set of possibilities :

1) make a wrapper lib around the plug-in and put that in prefix/lib
2) the reverse, make a lib and a wrapper plug-in
3) symlinking the plugin lib to prefix/lib (this works)

Let me know which you would prefer.

b) libgstgconf.so

Steveb and I have been working a little with this, and I've come to the 
conclusion that there's no reason for this to be a plug-in at all.
It's a pure helper lib.

So I've moved the installation location to prefix/lib.

Also, it's time to start thinking about a set of helper routines which 
wtay wants out of the core for bloat reasons, but which I'd like to put in 
and promote to app developers to help.

steveb suggested a library for parsing routines, one function for which I 
currently put in the gstgconf library, to render a partial description to 
a bin and ghost the unconnected src and sink pads.

I'm sure there'll be more in the future like this.

I'm wondering where this code should be going.  Wim wants it out of the 
core (as well as some other code in gstutils), which is ok for me.
I'd be inclined to move gstgconf along with it, as well as some of the 
parsing code maybe, or parsing helper code, to a separate module.
This module would probably also provide the gconf schema's, and 
consequently required by all actual apps using some of this stuff.

We should decide where we want these bits of code, so we can start working 
on them.  What do you guys think ?

Thomas

-- 

The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
<-*-                      -*->
The blood before me makes me open up my heart again
And I feel it coming over like a storm again
<-*- thomas at apestaart.org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/