In Windows, EXE and DLL have version info, including at least the following fields:

  1. file version
  2. product version
  3. internal name
  4. product name
  5. copyright

In Linux Library / Executable:

  • Which fields are present?
  • How to view such info?
  • What tools/libraries to read?
  • i have updated some more things please check now.. Commented Dec 19, 2012 at 7:25
  • ldconfig need root? What about to check a specific libxxx.so file and don't want to execute an exe with --version (it may fail)
    – linquize
    Commented Dec 19, 2012 at 7:28
  • no need root, since /sbin/ path is not set in normal user Environment, you can execute that useing absolute path eg. /sbin/ldconfig -p Commented Dec 19, 2012 at 7:32

7 Answers 7


The version info in not explicitly stored in an ELF file. What you have in there is the name of the library, the soname, which includes the major version. The full version is usually stored as a part of the library file name.

If you have library, say libtest.so, then you usually have:

  • libtest.so.1.0.1 - The library file itself, containing the full version
  • libtest.so.1 - Symlink to libtest.so.1.0.1, having the same name as soname
  • libtest.so - Symlink to libtest.so.1 used for linking.

In the library file libtest.so.1.0.1, there will be an entry called SONAME in dynamic section, that will say this library is called libtest.so.1. When you link a program against this library, the linked program will store the soname of the library under NEEDED entry in the dynamic section.

If you want to verify, what exactly is in which ELF file, you can try to run:

readelf -a -W elffile

where elffile can be either an library of an executable.

If you simply want to get the library version, you can play with:

readelf -d  /path/to/library.so |grep SONAME

AFAIK, there's no such info (at least not by default) in executable files.

Or you can rely on the program itself or your packaging system, as Rahul Patil wrote.

  • nice info, it's new to me never used readelf, if you don't mind , may i ask you where & why use readelf Commented Dec 19, 2012 at 7:37
  • 2
    Readelf (and similar tools) is useful, when you want to look inside an elf file :). I use it mostly when programming to look up symbols in libraries (when something doesn't work), or when there's some problem with a library. (man readelf)
    – v154c1
    Commented Dec 19, 2012 at 8:14

You can use ldconfig -v | grep libraryname , also command has option command -V or binaryfile --version

example :

test@ubuntukrb12:~# ls --version
ls (GNU coreutils) 8.13
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

also you can use yum or aptitude based on distro you are using eg.

in RHEL5/CENTOS5/Fedora you can use yum info packagename or if it installed then use rpm --version packagename

 [root@ldap1 ~]# yum info bind97
    Loaded plugins: downloadonly, fastestmirror, security
    Loading mirror speeds from cached hostfile
     * base: mirrors.sin3.sg.voxel.net
     * epel: mirror.imt-systems.com
     * extras: mirrors.sin3.sg.voxel.net
     * updates: mirrors.sin3.sg.voxel.net
    Installed Packages
    Name       : bind97
    Arch       : i386
    Epoch      : 32
    Version    : 9.7.0
    Release    : 10.P2.el5_8.4
    Size       : 6.3 M
    Repo       : installed
    Summary    : The Berkeley Internet Name Domain (BIND) DNS (Domain Name System) server
    URL        : http://www.isc.org/products/BIND/
    License    : ISC
    Description: BIND (Berkeley Internet Name Domain) is an implementation of the DNS
               : (Domain Name System) protocols. BIND includes a DNS server (named),
               : which resolves host names to IP addresses; a resolver library
               : (routines for applications to use when interfacing with DNS); and
               : tools for verifying that the DNS server is operating properly.

In Ubuntu You can use aptitude show pkgname or dpkg --version pkgname

root@ubuntukrb12:~# aptitude show bind9utils
Package: bind9utils
State: installed
Automatically installed: yes
Version: 1:9.8.1.dfsg.P1-4ubuntu0.4
Priority: optional
Section: net
Maintainer: Ubuntu Developers <[email protected]>
Architecture: amd64
Uncompressed Size: 306 k
Depends: libbind9-80, libc6 (>= 2.14), libdns81, libisc83, libisccc80, libisccfg82
Conflicts: bind9utils
Replaces: bind9 (<= 1:9.5.0~b2-1), bind9 (<= 1:9.5.0~b2-1)
Description: Utilities for BIND
 This package provides various utilities that are useful for maintaining a working BIND installation.
  • For rpm, I think you'll want rpm --query pkgname to list the version string (rpm --version will print the version of rpm itself; the same might be true for dpkg)
    – hoc_age
    Commented Sep 16, 2014 at 14:19

Run this to get version information - strings libssl.so.1.0.0 | grep "1\.0"

SSLv3 part of OpenSSL 1.0.2p-fips  14 Aug 2018
OpenSSL 1.0.2p-fips  14 Aug 2018
TLSv1 part of OpenSSL 1.0.2p-fips  14 Aug 2018
DTLSv1 part of OpenSSL 1.0.2p-fips  14 Aug 2018
  • All the package-system based solutions do not necessarily give definitive version information. This can make a difference when it comes to shared libs installed by custom packages (as in my case) or locally compiled libs. This simple -albeit a bit crude- solution delivers, where even a tool such as readelf failed for me. I only feel a bit embarrased I found this post before thinking of this solution myself :-). Thanks!
    – Hkoof
    Commented Apr 2, 2020 at 11:27
  • this is what I needed, because I needed to check a library that was not installed by the package manager but rather linked by a specific program. This gave me the information I needed. Commented Nov 7, 2020 at 10:03
  • This only happens to work because this library has that text as bare strings. It isn't a general solution.
    – mattdm
    Commented Apr 23, 2022 at 14:07

For Redhat based systems do this:

ldd [file you want to run] | > needed-packages

Check out needed-packages file, make sure there are no path names in the library file names. If so remove them, so "/bin/lib/libx.so.1" change to "libx.so.1"

Find out what package contains the library

yum -y provides [lib name]

Or put this into a script or run from cmd line:

for lib in `cat libs.txt`;
   yum -y provides $lib | head -2 | grep " : " >> packages.list

Next, create the following script or run from cmd line:

for package in `cat packages.list | awk '{ print $1 }'`;
    yum -y install $package

You're done, run your program. If you get GUI errors when running. Copy them down and if they are library references, find the packages for those and install the same way.


The fundamental answer is that there is no such standard metadata in Linux executable and library binary files. Usually, asking the distribution's package manager is the best you can do — or, as some examples have shown in other answers, hope that the program itself happens to include identifying strings.

With the (upcoming at the time of this writing) Fedora Linux 36 release, we are adding package information to ELF objects. There is a proof of concept for doing this for Debian as well.

Once this is in place, you can do (for example):

$ readelf --notes /lib/libedit.so.0 |grep -A3 .note.package
Displaying notes found in: .note.package
  Owner                Data size    Description
  FDO                  0x00000084   FDO_PACKAGING_METADATA
    Packaging Metadata: {"type":"rpm","name":"libedit","version":"3.1-41.20210910cvs.fc36","architecture":"i386","osCpe":"cpe:/o:fedoraproject:fedora:36"}

... and then from there, you can get the package info which will include other information, including the license, project URL, and so on.


I guess you need this

pkg-config libgcrypt --modversion

This command queries the content /usr/lib/pkgconfig/libgcrypt.pc, giving you exactly the same result as pacman -Qi libgcrypt.


On rpm-based systems you can use "rpm -qf library_with_path" to determine the version and release of the package containing library_with_path.

Old UNIX versions had a what command (see also GNU replacement) that (AFAIR) searches for strings starting with @(#) (that was unlikely to occur in binaries at the time the utility was written).

The RCS package also features an utility named ident that searches for "RCS keywords" (actually it should search for expanded RCS keywords, but it has a rather loose logic, so it finds all other kinds of strings, specifically in shell or Perl scripts).

Linux also seems to keep track which library version introduced which symbol, so you could use the objdump command (e.g.) to see that information:

objdump -T /usr/lib64/libxml2.so.2 |
awk 'NF == 7 && $2 == "g" { print $6 "\t" $7 }' |
sort -n |

(Version of objdump is from GNU binutils 2.41.0)

For example the output could be:

Base    compute_minrun
Base    __docbDefaultSAXHandler
Base    _fini
Base    get_max_nodeset_len
Base    htmlDecodeEntities
LIBXML2_2.9.0   xmlSchemaValidateSetLocator
LIBXML2_2.9.0   xmlTextWriterSetQuoteChar
LIBXML2_2.9.1   LIBXML2_2.9.1
LIBXML2_2.9.1   xmlXPathNodeEval
LIBXML2_2.9.1   xmlXPathSetContextNode

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .