On Fri, Apr 24, 2015 at 8:06 AM, Ralf Mardorf
<ralf.mardorf@xxxxxxxxxxxxxx> wrote:
> On Fri, 24 Apr 2015 06:41:27 +0200, Ralf Mardorf wrote:
>>On Thu, 23 Apr 2015 22:56:56 +0300, Jesse Jaara wrote:
>>>What you need to do is to create a custom package for the specific
>>>version of libvpx that doesn't conflict with the one from repo, so you
>>>can have both the new version for repo packages and the old version
>>>for whatever reason
>>
>>Yes, I was thinking of simply installing the new package and copying
>>/usr/lib/libvpx.so.1.3.0
>>from a backup and add the links
>>/usr/lib/libvpx.so.1
>>/usr/lib/libvpx.so.1.3
>>manually, instead of building a package for the old version.
>>
>>However, I can't do this for
>>/usr/lib/libvpx.so
>>and the bins, that perhaps aren't needed from the old package.
>
> It works :).
This is because of the so called SONAME. That is the name in a shared
library that will be to look for it when it is used in a program.
Usually, in standard linux packages the SONAME of a shared library
includes only the major version number.
For example, with the latest version:
$ objdump -p /usr/lib/libvpx.so | grep SONAME
SONAME libvpx.so.2
And with an old one, I assume:
$ objdump -p /usr/lib/libvpx.so.1.3.0 | grep SONAME
SONAME libvpx.so.1
You can check the SONAME used by VirtualBox with this command:
$ objdump -p /usr/lib/virtualbox/components/VBoxC.so | grep vpx
NEEDED libvpx.so.2
And check whether the file is found with:
$ ldd /usr/lib/virtualbox/components/VBoxC.so | grep libvpx
libvpx.so.2 => /usr/lib/libvpx.so.2 (0x00007f095d9e8000)
The bottom line is that if the conflict is between different major
version of the library, no problem: just copy "libvpx.so.1" to
/usr/lib/ or /usr/local/lib/.
The "libvpx.so" symbolic link exists because it will be the library
name used to build new programs, but it is not needed in runtime.
HTH
--
Rodrigo
