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

[Emil Velikov]

On 23/06/14 21:21, Aaron Watry wrote:
> On Mon, Jun 23, 2014 at 1:54 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 23/06/14 19:31, Aaron Watry 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 at 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
>>>
>> In case you're interested you can check the i-node for each file (ls -i) where
>> both libvdpau*1.0.0 should link to the same one.
>>
>> Above files look good. I'm guessing that this is with the linked patch ?
>>
> 
> Yeah, that's with the patch.  I just did an ls -i, and the files do
> indeed reference the same i-node.  This matches with the previous
> check I had done before the patch (du -sk /usr/local/lib/vdpau roughly
> matched the size of one of the links, not the sum of both).
> 
Great, now all we need is for distros to package them properly preserving the
hardlink :)

>>> Then I run ldconfig:
>>> awatry at ws-awatry:/usr/local/lib/vdpau$ sudo ldconfig
>>>
>> Rather silly question but why ? AFAIK the vdpau backend explicitly dlopened,
>> thus you should not need ldconfig here.
> 
> The first time that I discovered this was before I knew that libvdpau
> only checked it's compile-time prefix for back-end drivers.  I had
> added /usr/local/lib/vdpau to /etc/ld.so.conf.d/vdpau.conf on my
> system in an attempt to add my vdpau libraries to the library path.
> It was a dead-end because of the hard-coded vdpau back-end paths, but
> the discovery that the link is getting created after install by the
> next ldconfig run was intriguing which is why I called it out.
> 
> My system is set up with all distro-provided packages under
> /usr/lib/{arch}/, and all of my hand-compiled stuff under
> /usr/local/lib (64-bit only).  My library path allows /usr/local/lib
> to override /usr/lib/{arch}, but only for packages that I've bothered
> to rebuild myself.  At this point, that includes waffle, glamor, mesa,
> libclc, xf86-video-ati, and LLVM.  It does NOT include libvdpau, as I
> had never known a reason to build that myself.  Now, I'll either rely
> on my distro's vdpau-backend drivers, add libvdpau to the list of
> packages I'm building myself, or just symlink
> /usr/lib/x86_64-linux-gnu/vdpau to /usr/local/lib/vdpau.
> 
Makes sense, thanks for clarifying.

AFAIK pretty much every library provided by mesa follows the rule - Is it
installed in ${libdir} ?
- No, dlopen only.
- Yes, dlopen/link against it.

-Emil

> --Aaron
>