Re: [opensuse-factory] Applications linking against both gstreamer-0.10 and gstreamer-1.0
Am 06.02.13, schrieb Marcus Meissner <meissner@suse.de>:
Patching gstreamer to version symbols? In the fast and ugly way: versioning *all* symbols with "GST_0.10" and/or "GST_1.0", it should be easy. But it would be good to double check if other distributions have already done this to use the same version string.
You will have to maintain this symbol versioning forever if you start doing it. ;)
Hi Marcus, this sounds like this is a burden of some kind. What are the maintenance costs? - normally, this shoud be a one time effort, as long as the gstreamer build system does not change and gstreamer stays at "GST_1.0". Would an upstream patch change this situation? (Also asking because inkscape has a similar problem with poppler. Direct use of libpoppler (opposed to its qt, glib, ... wrappers) is discouraged by poppler, but necessary in this specific case. popplers ABI changes frequently). Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Feb 06, 2013 at 02:15:43PM +0100, "Stefan Brüns" wrote:
Am 06.02.13, schrieb Marcus Meissner <meissner@suse.de>:
Patching gstreamer to version symbols? In the fast and ugly way: versioning *all* symbols with "GST_0.10" and/or "GST_1.0", it should be easy. But it would be good to double check if other distributions have already done this to use the same version string.
You will have to maintain this symbol versioning forever if you start doing it. ;)
Hi Marcus,
this sounds like this is a burden of some kind. What are the maintenance costs? - normally, this shoud be a one time effort, as long as the gstreamer build system does not change and gstreamer stays at "GST_1.0".
Would an upstream patch change this situation?
(Also asking because inkscape has a similar problem with poppler. Direct use of libpoppler (opposed to its qt, glib, ... wrappers) is discouraged by poppler, but necessary in this specific case. popplers ABI changes frequently).
If upstream would accepted this, it would be fine. Otherwise we really have to continue to maintain it here, to provide compatibility to older versions (and third party apps built against it). So first try to convince upstream to do it :/ Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Quoting Marcus Meissner <meissner@suse.de>:
Would an upstream patch change this situation?
(Also asking because inkscape has a similar problem with poppler. Direct use of libpoppler (opposed to its qt, glib, ... wrappers) is discouraged by poppler, but necessary in this specific case. popplers ABI changes frequently).
If upstream would accepted this, it would be fine.
Due to the identified GType registration clashes, which are likely not resolvable, I don't see much chance for that anymore. Thus, carrying a patch would result in a 100% non-portable binary generation on openSUSE: no binary created with openSUSE 12.3 linking Gstreamer could be shared with ANY OTHER Linux distribution. Thus I don't think openSUSE should consider this option. so the only solution we have are: - Disable libcanberra-gtk module loading (we will loose some notification sounds) - Port apps to GStreamer 1.0 (as requested as target at the beginning of 12.3 cycle). - Life with the crashes. For the GstMixer interface removal: upstream considers this highly broken and that's the reason it was removed. Any implementation of a mixer is supposed to interact with either PA,Alsa,OSS,<sound daemon> on it's own. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 6 February 2013 16:04, Dominique Leuenberger a.k.a. Dimstar <dimstar@opensuse.org> wrote:
Quoting Marcus Meissner <meissner@suse.de>:
Would an upstream patch change this situation?
(Also asking because inkscape has a similar problem with poppler. Direct use of libpoppler (opposed to its qt, glib, ... wrappers) is discouraged by poppler, but necessary in this specific case. popplers ABI changes frequently).
If upstream would accepted this, it would be fine.
Due to the identified GType registration clashes, which are likely not resolvable, I don't see much chance for that anymore.
After expending ten minutes into this... definitely I am going to need some explanation about those "GType registration clashes" to understand the problem.
Thus, carrying a patch would result in a 100% non-portable binary generation on openSUSE: no binary created with openSUSE 12.3 linking Gstreamer could be shared with ANY OTHER Linux distribution.
Why? Again, from http://www.akkadia.org/drepper/symbol-versioning "The last case is if the object with the references uses symbol versions but the object with the definitions has none. In this case a matching symbol is accepted unless the object's name matches the one in the Elfxx_Verneed entry." So our binaries would continue working with unversioned gstreamers from other distributions (here I'm quite sure that with a warning from the linker).
Thus I don't think openSUSE should consider this option.
so the only solution we have are: - Disable libcanberra-gtk module loading (we will loose some notification sounds)
Is this the only possible path to both gstreamers being loaded in the same process image? I expect to be others.
- Port apps to GStreamer 1.0 (as requested as target at the beginning of 12.3 cycle).
Ideal solution... But I don't think we have the resources for this. Not to mention Packman, which is not currently in it best shape.
- Life with the crashes.
Not nice. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Cristian Morales Vega <reddwarf@opensuse.org> [2013-02-06 23:01]:
On 6 February 2013 16:04, Dominique Leuenberger a.k.a. Dimstar <dimstar@opensuse.org> wrote:
Quoting Marcus Meissner <meissner@suse.de>:
Would an upstream patch change this situation?
(Also asking because inkscape has a similar problem with poppler. Direct use of libpoppler (opposed to its qt, glib, ... wrappers) is discouraged by poppler, but necessary in this specific case. popplers ABI changes frequently).
If upstream would accepted this, it would be fine.
Due to the identified GType registration clashes, which are likely not resolvable, I don't see much chance for that anymore.
After expending ten minutes into this... definitely I am going to need some explanation about those "GType registration clashes" to understand the problem.
Thus, carrying a patch would result in a 100% non-portable binary generation on openSUSE: no binary created with openSUSE 12.3 linking Gstreamer could be shared with ANY OTHER Linux distribution.
Why? Again, from http://www.akkadia.org/drepper/symbol-versioning
"The last case is if the object with the references uses symbol versions but the object with the definitions has none. In this case a matching symbol is accepted unless the object's name matches the one in the Elfxx_Verneed entry."
So our binaries would continue working with unversioned gstreamers from other distributions (here I'm quite sure that with a warning from the linker).
Thus I don't think openSUSE should consider this option.
so the only solution we have are: - Disable libcanberra-gtk module loading (we will loose some notification sounds)
Is this the only possible path to both gstreamers being loaded in the same process image? I expect to be others.
That's likely, the relatively easy to find cases like libcanberra which is now built without gstreamer support or rygel which was the only case where both gstreamer version where directly linked to should be fixed now. If the problem cannot be fixed on the gstreamer side by using symbol versioning then we should at least make the effort to identify the issues within the distro. However that isn't straightforward as e.g. Firefox illustrates, any ideas how to address this systematically? There is also quite a few libraries which still link to gstreamer-0.10 like or QtWebKit some wxgtk stuff, it should probably be noted in the release notes that these must not be combined with gstreamer-1.0.
- Port apps to GStreamer 1.0 (as requested as target at the beginning of 12.3 cycle).
Ideal solution... But I don't think we have the resources for this. Not to mention Packman, which is not currently in it best shape.
Some packages like e.g. xfce4-volumed, xfce4-mixer, or gmixer also cannot be ported to newer gstreamer versions since the parts of the API they are built around were removed without replacement. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Quoting Guido Berhoerster <gber@opensuse.org>:
That's likely, the relatively easy to find cases like libcanberra which is now built without gstreamer support or rygel which was the only case where both gstreamer version where directly linked to should be fixed now. If the problem cannot be fixed on the gstreamer side by using symbol versioning then we should at least make the effort to identify the issues within the distro. However that isn't straightforward as e.g. Firefox illustrates, any ideas how to address this systematically? There is also quite a few libraries which still link to gstreamer-0.10 like or QtWebKit some wxgtk stuff, it should probably be noted in the release notes that these must not be combined with gstreamer-1.0.
Indeed a good thing to document. And a clear action item for 13.1: we must make it a high prio target to eliminate Gst 0.10 from the tree (or, at least only provide it for convenience to 3rd parties... it's an unmaintained code base).
- Port apps to GStreamer 1.0 (as requested as target at the beginning of 12.3 cycle).
Ideal solution... But I don't think we have the resources for this. Not to mention Packman, which is not currently in it best shape.
Some packages like e.g. xfce4-volumed, xfce4-mixer, or gmixer also cannot be ported to newer gstreamer versions since the parts of the API they are built around were removed without replacement.
Talking to Gst upstream about this issue leads to the point that GstMixer was apparently heavily broken (it always depends on who you ask... seems the xfce devs were fine with it)_ and they recommend to use alsa / PA backends directly to get a sane code base... This for sure should not become a long-term blocker for the removal of Gst 0.10. Best regards, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Dominique Leuenberger a.k.a. Dimstar <dimstar@opensuse.org> [2013-02-08 11:27]:
Quoting Guido Berhoerster <gber@opensuse.org>:
That's likely, the relatively easy to find cases like libcanberra which is now built without gstreamer support or rygel which was the only case where both gstreamer version where directly linked to should be fixed now. If the problem cannot be fixed on the gstreamer side by using symbol versioning then we should at least make the effort to identify the issues within the distro. However that isn't straightforward as e.g. Firefox illustrates, any ideas how to address this systematically? There is also quite a few libraries which still link to gstreamer-0.10 like or QtWebKit some wxgtk stuff, it should probably be noted in the release notes that these must not be combined with gstreamer-1.0.
Indeed a good thing to document. And a clear action item for 13.1: we must make it a high prio target to eliminate Gst 0.10 from the tree (or, at least only provide it for convenience to 3rd parties... it's an unmaintained code base).
- Port apps to GStreamer 1.0 (as requested as target at the beginning of 12.3 cycle).
Ideal solution... But I don't think we have the resources for this. Not to mention Packman, which is not currently in it best shape.
Some packages like e.g. xfce4-volumed, xfce4-mixer, or gmixer also cannot be ported to newer gstreamer versions since the parts of the API they are built around were removed without replacement.
Talking to Gst upstream about this issue leads to the point that GstMixer was apparently heavily broken (it always depends on who you ask... seems the xfce devs were fine with it)_ and they recommend to use alsa / PA backends directly to get a sane code base...
Well in this case I am also the upstream maintainer of xfce4-mixer and based on the upstream bug reports I don't see any indication that it is heavily broken, the only thing that has always been heavily broken is the pulseaudio backend. As a matter of fact, the default GNOME mixer gst-mixer was based of the gstinterfaces library for many years. Using alsa or PA directly is also not acceptable since Xfce still has a wider scope than just supporting Alsa on Linux or relying on PA which does not work very well or is not available on all platforms Xfce supports. gstinterfaces provided a reasonably good abstraction over Alsa, OSS on BSD, OSSv4/Boomer on Solaris, and legacy Solaris sunaudio for which there is no replacement. And Since the current mixer is closely built around the GstMixer API, even porting to some other library would practically mean to rewrite it from scratch, something that is not going to happen, particularly not since I just put considerable effort into improving it a couple of months ago. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (5)
-
"Stefan Brüns" -
Cristian Morales Vega -
Dominique Leuenberger a.k.a. Dimstar -
Guido Berhoerster -
Marcus Meissner