neil at qualityassistant.com
Tue Feb 25 01:42:28 GMT 2003
-----BEGIN PGP SIGNED MESSAGE-----
On Monday February 24, 2003 05:10, Havoc Pennington wrote:
> Neil wrote:
> > Oh, while I'm thinking of it, does glib guarantee binary compatibility
> > for the lengths of time that a major KDE version lasts?
> GLib guarantees binary compatibility literally forever; when the ABI
> changes every file installed by GLib is renamed or moved. See
> http://ometer.com/parallel.html for some of the background on that.
> So right now you would link to -lglib-2.0, but for old GLib there's
> -lglib-1.2 still installed. You can compile against and link against
> and run against GLib 1.2 even though GLib 2.0 has been out for I think
> a couple years now.
> -lglib-3.0 probably won't appear for another couple years from now (so
> new ABIs that require the rename/move are typically introduced every
> 4-5 years).
The library naming really sidesteps the issue. If glib 3.0 comes out 3
months after KDE 4 comes out, and GStreamer development moves to it, then
KDE gets stuck with an unmaintained version of glib and GStreamer for the
life of KDE 4. The compatibility within a version is nice, but we also
need a library that will keep compatible for long stretches of time.
But, if glib versions will stay compatible for years, then I doubt that'd
be a problem. The issue then becomes GStreamer's own compatibility.
> To me the real point about GLib is this thought experiment:
> - imagine you write all your own custom equivalents for glib in
> gstreamer, and don't use glib
> - now imagine you cut-and-paste the glib code you need into gstreamer
> - now explain the difference between those two cases
> To me if there's no difference there, the real issue is just whether
> you want to cut-and-paste/static-link vs. dynamically link to glib.
> For example pkg-config sucks in its own copy of GLib so people won't
> complain about the dependency. (Of course now they complain about it
> having its own copy, but you can't win ;-)
Well, actually, I sorta like the idea of KDE users being able to build
GStreamer with a static glib. If we go with GStreamer I'll have to look
at building it that way, and even packaging it all together for
But linking isn't my complaint. Developing is my complaint. KDE
developers shouldn't have to be glib developers. KDE developers should be
able to extend the KDE-chosen media system without learning some C
> Well, I don't know anything about multimedia, but hopefully the above
> is useful information about GLib policies/intentions.
It was useful. Though I'd visited #gnome on irc.gnome.org just a couple
hours ago and gotten basically the same ABI answer. :-)
Neil Stevens - neil at qualityassistant.com
"Distinctions by race are so evil, so arbitrary and insidious that a
state bound to defend the equal protection of the laws must not allow
them in any public sphere." -- Thurgood Marshall
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the kde-multimedia