Branden Robinson wrote:
> Real world example: there is a plugin for XMMS called "smpeg-xmms" that
> uses the SMPEG library, which is based on SDL, to playblack MPEG movies.
>
> Now, XMMS itself doesn't use SDL, or the aforementioned static X
> extension libraries. Therefore it has no reason to contain these static
> objects in its binary.
The exact same situation is coming up, but more so, with GStreamer.
GStreamer is in the long run a glib-2.0-based (mostly gtk-1.2-based for
now) library for streaming multimedia that's totally plugin-oriented.
Nothing *at all* happens without plugins. Now, we have an xvideosink that
uses Xv if it exists and is supported. The Debian package maintainer then
has been smacked around for creating .deb's of that plugin that have a .so
plugin linked to the static libXv.a. lintian has a cow (I presume).
There are other instances of this, such as libmad (a mp3 decoder), but at
least there we can do ./configure --enable-shared and bypass the problem,
esp. since the Debian package maintainer does that AFAIK. I certainly
have for my RPM's of it.
This problem has to be resolved, and while the idea of a libxyz_pic.a is
viable perhaps, it's not the Correct(tm) solution. Correct solution is to
make them shared libs with proper versioning (and versioned headers as
necessary). Until it is, Debian is gonna have to keep granting (or worse,
not) exceptions for packages that have to work around these libraries, and
for archs where it just plain doesn't work at all, people are simply
screwed.
Erik Walthinsen <[EMAIL PROTECTED]> - System Administrator
__
/ \ GStreamer - The only way to stream!
| | M E G A ***** http://gstreamer.net/ *****
_\ /_
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
