On Fri, Apr 24, 2015 at 8:06 AM, Ralf Mardorf <ralf.mardorf@rocketmail.com> 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