Bug#880884: marked as done (qtav: Adapt to libva 2)
On 2017-11-13 19:38:38, Pino Toscano wrote:
> In data lunedì 13 novembre 2017 12:06:01 CET, Steve Robbins ha scritto:
> > On Sunday, November 12, 2017 7:21:30 PM CST Sebastian Ramacher wrote:
> >
> > > > [ Pino Toscano ]
> > > > * Remove manual library and va-driver dependencies. (Closes: #880884)
> > >
> > > I am afraid that this change is not enough. qtav still needs to be ported to
> > > the new libva. Currently it links libva2,
> >
> > Concretely, what needs to be "ported"? The sources build against libva2 as
> > you say. Aside from dlopen issues, below, what needs to change?
> >
> > > but dlopens libva.so.1,
> > > libva-x11.so.1, and maybe others.
>
> Sebastian: this would have been nice to know when the bug was filed
> (or as additional comments), instead of only when reopening it later
> on...
Sorry, but I didn't know at that time. I only noticed it after fixing a similar
issue in libva itself.
Cheers
>
> > How did you determine this? I looked for dlopen in the code and found
> > nothing. Grepping for "libva" came up only with this code setting a
> > "detail_display" property.
>
> It is a bit more complex than that: see in src/vaapi/vaapi_helper.h/cpp
> a) the dll_helper class, its constructor in particular
> b) all the various dll_helper subclasses, and how they pass "1" as
> version for the library to load
>
> The even more funny part is that libQtAV.so actually links to libva (and
> thus it gets the proper shlibs dependency), although it will try to
> dlopen it later on! This is funky (to say it mildly), and QtAV ought
> to better link to libva* if found during build.
>
> A simple solution could be to adapt to "2" all the libva versions
> there, but also checking that all the symbols dynamically loaded
> actually are what libQtAV expects (parameters, semantics, etc).
> A more complex solution is, of course, to properly link to the used
> libraries... Both of them need some feedback from upstream.
>
> --
> Pino Toscano
--
Sebastian Ramacher
Reply to: