4

I am sure there are several ways to do this, but is there a tool built into Ubuntu or a recommended way to check the version of any given library you have installed on an ubuntu server?

wjimenez5271
  • 709
  • 2
  • 6
  • 16

1 Answers1

3

First off. Sometimes when people talk about libraries they are talking about .deb packages that provide libraries to other packages. We'll deal with that case first. The other context you hear the term library used in is the traditional .so shared object sense. We'll deal with that second.

apt-cache depends <package_name> will return a list of packages that are dependencies for <package name>. Packages are not necessarily congruous with libraries (i.e., libraries in the sense of linkable .so files), but in Debian and Ubuntu libraries are generally packaged as lib<something>. If you do a dpkg -l |grep <library package name> you can find which package containing which libraries is installed.

kelliott@mis-ke-lnx:~$  apt-cache depends perl
perl
  Depends: perl-base
  Depends: perl-modules
  Depends: libbz2-1.0
  Depends: libc6
  Depends: libdb4.7
  Depends: libgdbm3
  Depends: zlib1g
kelliott@mis-ke-lnx:~$ dpkg -l |grep libc6
ii  libc6                                    2.11.2-10                         Embedded GNU C Library: Shared libraries
ii  libc6-dev                                2.11.2-10                         Embedded GNU C Library: Development Libraries and Header Files

Or you can go the other way. If you're wondering what package required the package libwww-perl you can use this handy little perl script to return a list of libwww-perl reverse dependencies that are also installed.

#!/usr/bin/env perl
use strict;
use warnings;

use AptPkg::Cache;
my $cache = AptPkg::Cache->new;

my $pkg = $ARGV[0]
    or die 'supply a package name as the first arg';

my @acrd = split /\s+/, `apt-cache rdepends $pkg`;

my $state;
for (@acrd) {
    unless ( $_ eq 'Reverse' or $_ eq 'Depends:' ) {
        $state = $cache->{$_}->{'CurrentState'};
        print "$_\n" if $state eq 'Installed';
    }
}

Now the .so shared object files are a little different. I like to use a combination of ldd and apt-file. Let's say I'm interested in the object files linked against ls:

kelliott@mis-ke-lnx:~$ ldd /bin/ls
    linux-vdso.so.1 =>  (0x00007fff8b05d000)
    libselinux.so.1 => /lib/libselinux.so.1 (0x00007fcfb7e24000)
    librt.so.1 => /lib/librt.so.1 (0x00007fcfb7c1c000)
    libacl.so.1 => /lib/libacl.so.1 (0x00007fcfb7a14000)
    libc.so.6 => /lib/libc.so.6 (0x00007fcfb76b3000)
    libdl.so.2 => /lib/libdl.so.2 (0x00007fcfb74af000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fcfb8057000)
    libpthread.so.0 => /lib/libpthread.so.0 (0x00007fcfb7292000)
    libattr.so.1 => /lib/libattr.so.1 (0x00007fcfb708e000)
kelliott@mis-ke-lnx:~$ apt-file search libattr.so.1
    ia32-libs: /lib32/libattr.so.1
    ia32-libs: /lib32/libattr.so.1.1.0
    libattr1: /lib/libattr.so.1
    libattr1: /lib/libattr.so.1.1.0
kelliott@mis-ke-lnx:~$ dpkg -l |grep libattr1
    ii  libattr1                                 1:2.4.44-2                        Extended attribute shared library
kelliott@mis-ke-lnx:~$ file /lib/libattr.so.1
/lib/libattr.so.1: symbolic link to `libattr.so.1.1.0'
kelliott@mis-ke-lnx:~$ file /lib/libattr.so.1.1.0
/lib/libattr.so.1.1.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped

As you can see our good friend ls has quite a few libraries linked against it. libattr.so.1 handles file attributes if I remember correctly. Doing an apt-file search against it shows that it was installed by two packages ia32-libs and libattr1 (one for 32bit and one for 64bit). And on my system it looks like the libattr1 package (at version 1:2.4.44-2) installed the libattr.so shared object file, which upon further investigation is at version 1.1.0.