The vdpau loader requires only major, and falls back to an unversioned SO.
Thus IMHO we should keep at least the major.
In the future we might want to move to a versioning scheme similar to nvidia,
which lacks the revision number, thus we'll be OK with the BSD guys :)
libvdpau_nvidia.so -> libvdpau_nvidia.so.1
libvdpau_nvidia.so.1 -> libvdpau_nvidia.so.319.22
libvdpau_nvidia.so.319.22
libvdpau_nouveau.so -> libvdpau_nouveau.so.1
libvdpau_nouveau.so.1 -> libvdpau_nouveau.so.10.2
libvdpau_nouveau.so.10.2
-Emil
On 23/06/14 19:45, Marek Olšák wrote:
> On a different note, do we really need the suffixes .1.0.0 etc.? It's
> not like the version is going to change.
>
> Marek
>
> On Mon, Jun 23, 2014 at 8:31 PM, Aaron Watry <awa...@gmail.com> wrote:
>> Using /usr/local as PREFIX and an empty /usr/local/lib/vdpau directory
>> to start, after make install of mesa I end up with
>> /usr/local/lib/vdpau/ containing:
>>
>> awatry@ws-awatry:/usr/local/lib/vdpau$ ls -l
>> total 26944
>> lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so ->
>> libvdpau_r600.so.1.0.0
>> lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1 ->
>> libvdpau_r600.so.1.0.0
>> lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1.0 ->
>> libvdpau_r600.so.1.0.0
>> -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_r600.so.1.0.0
>> lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so ->
>> libvdpau_radeonsi.so.1.0.0
>> lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1 ->
>> libvdpau_radeonsi.so.1.0.0
>> lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1.0
>> -> libvdpau_radeonsi.so.1.0.0
>> -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_radeonsi.so.1.0.0
>>
>> Then I run ldconfig:
>> awatry@ws-awatry:/usr/local/lib/vdpau$ sudo ldconfig
>>
>> And now /usr/local/lib/vdpau/ contains:
>> lrwxrwxrwx 1 root root 22 Jun 23 13:27 libvdpau_gallium.so.1 ->
>> libvdpau_r600.so.1.0.0
>> lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so ->
>> libvdpau_r600.so.1.0.0
>> lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1 ->
>> libvdpau_r600.so.1.0.0
>> lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1.0 ->
>> libvdpau_r600.so.1.0.0
>> -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_r600.so.1.0.0
>> lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so ->
>> libvdpau_radeonsi.so.1.0.0
>> lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1 ->
>> libvdpau_radeonsi.so.1.0.0
>> lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1.0
>> -> libvdpau_radeonsi.so.1.0.0
>> -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_radeonsi.so.1.0.0
>>
>>
>> Configuration:
>> $ ./configure --with-dri-drivers=
>> --with-dri-driverdir=/usr/local/lib/dri/ --enable-debug
>> --enable-opencl --enable-opencl-icd
>> --with-gallium-drivers=r600,radeonsi --enable-gles1 --enable-gles2
>> --enable-texture-float --with-egl-platforms=drm,x11 --enable-glx-tls
>> --enable-dri3 --enable-omx
>>
>>
>> And just in case it's useful,after building ${mesa_src_root}/lib/gallium has:
>> awatry@ws-awatry:~/src/mesa/lib/gallium$ ls
>> libMesaOpenCL.so libvdpau_r600.so libvdpau_r600.so.1.0.0
>> libvdpau_radeonsi.so.1.0 radeonsi_dri.so
>> libMesaOpenCL.so.1 libvdpau_r600.so.1 libvdpau_radeonsi.so
>> libvdpau_radeonsi.so.1.0.0
>> libMesaOpenCL.so.1.0.0 libvdpau_r600.so.1.0 libvdpau_radeonsi.so.1
>> r600_dri.so
>> awatry@ws-awatry:~/src/mesa/lib/gallium$
>>
>> On Mon, Jun 23, 2014 at 1:12 PM, Emil Velikov <emil.l.veli...@gmail.com>
>> wrote:
>>> On 23/06/14 18:07, Aaron Watry wrote:
>>>> 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]*)
>>>>
>>> What do you mean with "force an ldconfig" ? Does [1] help ?
>>>
>>>> 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?
>>>>
>>>
>>> The path of the vdpau backends is hard-coded in libvdapu at build time.
>>> vdpau/master can pick the path via VDPAU_DRIVER_PATH but there is no vdpau
>>> release that has it afaik.
>>>
>>> -Emil
>>>
>>> [1] http://patchwork.freedesktop.org/patch/28378/
>>>
>>>> --Aaron
>>>>
>>>>
>>>> On Mon, Jun 23, 2014 at 11:42 AM, Emil Velikov <emil.l.veli...@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 --e--prefix you use to compile it. So if
>>>>>> you're putting mesa into anable-gbm --enable-shared-glapi
>>>>>> --enable-glx-tls --with-dri-drivers= && make -j5
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> mesa-dev mailing list
>>>>> mesa-dev@lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
