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 <davejpla...@gmail.com> wrote: > 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 <reddw...@opensuse.org> wrote: >> On 15 June 2012 18:25, Dominique Leuenberger a.k.a DimStar >> <dims...@opensuse.org> 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 >> _______________________________________________ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
