[Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)

[Aaron Watry]

On my machine, ${PREFIX}/lib/vdpau contains:
libvdpau_gallium.so.1 -> libvdpau_r600.so.1.0.0
libvdpau_r600.so*
libvdpau_radeonsi.so*

Note that libvdpau_gallium.so.1 is only created when I force an
ldconfig on my system (until then, I just have
libvdpau_[r600|radeonsi]*)

For some reason, while the files are in the same place, mplayer -vo
vdpau chokes on loading these files now.  If I copy
libvdpau_r600.so.1.0.0 to /usr/local/lib/libvdpau_r600.so, then
mplayer (-vo vdpau) picks it up and plays without issue.  Is the VDPAU
backend loader looking in the wrong directory?

--Aaron


On Mon, Jun 23, 2014 at 11:42 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 23/06/14 16:10, Andy Furniss wrote:
>> Emil Velikov wrote:
>>> Hi all,
>>>
>>> These patches add support for building (grouping) the various targets
>>> per API, meaning that only one library will be created  for e.g.
>>> vdpau (libvdpau_gallium) with individual ones (libvdpau_r600) being a
>>> hardlink to it.
>>
>> How is this supposed to work from a users point of view, by which I mean
>> that it seems if I build current mesa I no longer have vdpau.
>>
> Yes I had a few copy/paste typos that were causing make install to fall short
> when generating the (sym|hard)links. Should be fixed with commit 11e46a32aed.
>
> Let me know if latest master work for you.
>
> -Emil
>
>> Of course I do if I leave the old libs in place it still uses them, but
>> if I remove them I get no new links installed.
>>
>> ./autogen.sh --prefix=/usr --enable-texture-float
>> --with-egl-platforms=x11,drm --with-gallium-drivers=radeonsi,swrast
>> --enable-opencl --enable-vdpau  --enable-gbm --enable-shared-glapi
>> --enable-glx-tls --with-dri-drivers= && make -j5
>>
>>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev