If xine is going to be the only library that uses libavutil a static
version could make sense. But there is no reason to think that's going
to be the case. And then... really, I fail to see the problem here.
Could you please show a specific case where using a dynamic version of
libavutil there is a problem that isn't there when using a static one?
On 24 June 2012 13:47, Dave Plater
I have been working on a static build of libavutil included in the hg version of xine-lib but was having difficulty getting that version of xine-lib to build. Unfortunately I'm computerless atm but this would certainly solve the problem. Dave
On 6/15/12, Cristian Morales Vega
wrote: On 15 June 2012 18:25, Dominique Leuenberger a.k.a DimStar
wrote: Has this be well planned
Since xine 1.2.x depends on libavutil unconditionally (https://bugzilla.novell.com/show_bug.cgi?id=762784) it's basically the only solution.
But I don't see any real problem here. Can you put an specific combination of circumstances that would be problematic? It would be safer and easier if libavutil versioned symbols in a more detailed way instead of just to avoid using symbols from a library with a different soname, but that problem happens with lots of libraries that don't even version symbols at all. xine is the only package from openSUSE that will link against it. And the most common case is for users to use both xine and libavutil from Packman. So this seems 100% safe to me.
_______________________________________________ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org