Linux: Check the glibc version
If you need to check which version of the GNU C library (glibc) is used on you Linux system, whether it’s to check whether you are affected by the GHOST vulnerability or you need to install a software requiring at least a certain version but not checking it on build/installation, the easiest way is to use ldd which comes with glibc and should in most cases have the same version:
> ldd --version ldd (GNU libc) 2.11.1
If you know you might have patched the system to use a different version of ldd and know that its version doesn’t match the glibc version, you have two additional ways to find out the glibc version:
- Check the version of the installed glibc rpm package
- Check the version of the used libc.so file
> rpm -q glibc glibc-2.11.1-0.17.4
The second way is a little bit more difficult. You first have to find which libc.so file is being used by a known program e.g. netstat:
> ldd `which netstat` linux-vdso.so.1 => (0x00007ffff7ffb000) libc.so.6 => /lib64/libc.so.6 (0x00007ffff7a80000) /lib64/ld-linux-x86-64.so.2 (0x00007ffff7dde000)
You can also find the libc.so file used with the following command:
> cat `gcc -print-file-name=libc.so` /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf64-x86-64) GROUP ( /lib64/libc.so.6 /usr/lib64/libc_nonshared.a AS_NEEDED ( /lib64/ld-linux-x86-64.so.2 ) )
So we now know that /lib64/libc.so.6 is being used and we just need to get it’s version:
> /lib64/libc.so.6 --version GNU C Library stable release version 2.11.1 (20100118), by Roland McGrath et al. Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Configured for x86_64-suse-linux. Compiled by GNU CC version 4.3.4 [gcc-4_3-branch revision 152973]. Compiled on a Linux 2.6.32 system on 2010-05-06. Available extensions: crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B For bug reporting instructions, please see: .
If you want to determine the glibc version from C program and not from a shell script, you can just use something like this:
#include #include #include int main(int argc, char *argv[])
You can then compile it and execute it like this to get the glibc version:
> gcc glibc_version.c -o glibc_version > ./glibc_version glibc version: 2.11.1
Of course, if your C file is not called glibc_version.c, you’ll have to use the name you’ve actually used in the gcc arguments.
Since your current shell is probably also using glibc, you can also find out which libc library it has loaded by using the following command:
> lsof -p $$ | grep libc bash 9177 root mem REG 8,2 1661454 827401 /lib64/libc-2.11.1.so
Of course there may be systems where the file name itself doesn’t give you the glibc version but just as shown above with /lib64/libc.so.6 you can call the so file with the –version to get its version information e.g.:
lsof -p $$ | grep libc | awk ' < print $NF" --version"; >' | sh GNU C Library stable release version 2.11.1 (20100118), by Roland McGrath et al. Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Configured for x86_64-suse-linux. Compiled by GNU CC version 4.3.4 [gcc-4_3-branch revision 152973]. Compiled on a Linux 2.6.32 system on 2010-05-06. Available extensions: crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B For bug reporting instructions, please see: .
What’s the best way to check the version of a library on Ubuntu
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?
1 Answer 1
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 will return a list of packages that are dependencies for . 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 . If you do a dpkg -l |grep 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->->; 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.
Find out library version
I want to find out what version of a C library is installed in my system (Ubuntu 12.04). In particular, I’m interested in libnuma. What is the proper way to do it?
cd /usr/lib ls -l libnuma* -rw-r--r-- 1 root root 70312 Feb 8 2012 libnuma.a lrwxrwxrwx 1 root root 12 Feb 8 2012 libnuma.so -> libnuma.so.1 -rw-r--r-- 1 root root 43976 Feb 8 2012 libnuma.so.1
4 Answers 4
I would use dpkg -l | grep libnuma1 to get the version.
As an example, I have ran dpkg -l on xterm and you can see that I’m running versoin 278-4 of xterm.
# dpkg -l | grep xterm ii lxterminal 0.1.11-4 amd64 LXDE terminal emulator ii xterm 278-4 amd64 X terminal emulator
This works most of the time but not applicable when you compile and install the library, because dpkg does not care about libs/apps not installed by dpkg
While @SuB is correct, the fact is that without a packaging system, there’s no way to know what release an individual library was built from, as that information is managed by the packaging system and not contained in the library. The library itself only knows its API version (the number after the .so ). When you compile and install a library yourself, it’s up to you to keep track of where it came from (which is why packaging systems were created).
It gives me the output but at the beginning of the output there are these two lines. ldconfig: Can’t stat /libx32: No such file or directory . ldconfig: Can’t stat /usr/libx32: No such file or directory . Is that something to worry about?
ldconfig -v | grep libnuma shows libnuma.so.1 -> libnuma.so.1.0.0 , but dpkg -l | grep libnuma1 shows ii libnuma1:amd64 2.0.12-1 . This variant does not look reliable.
The file name or contents won’t always keep track of the exact version, so you’d typically want to use the packaging system facilities. For Ubuntu, you can either go to packages.ubuntu.com, search for your file, and see what version of the package is in your version of Ubuntu.
Or from the command line, you can first search for the name of the associated package using dpkg -S /usr/lib/libnuma.so.1 , which probably returns libnuma1 as the package name. Then run apt-cache showpkg libnuma1 to find the package version. The apt-cache output can be pretty long, but the version should be in the first few lines.
You must log in to answer this question.
Related
Hot Network Questions
Subscribe to RSS
To subscribe to this RSS feed, copy and paste this URL into your RSS reader.
Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.7.14.43533
By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.