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
