Find lib version linux

How to know library version?

where 2.6-3 looks completely uncomparable with 68 . How to know if it is greater or not? Here is an example of such a requirement, fmpeg building manual, section libx265 .

3 Answers 3

You should see something like:

libx265-dev Depends: libx265-179 (= 3.2.1-1build1) Suggests: libx265-doc 

The number after Depends: libx265- is the version number which should be ≥ 68.

The libx265-dev package is in the default repositories of Ubuntu 16.04 and later (at least until Ubuntu 22.10). In Ubuntu 18.04 open the terminal and type:

apt-cache show libx265-dev | grep Depends 

libx265-dev version in Ubuntu 18.04 is 146 which is ≥ 68.

I assume you require H.265/HEVC video stream encoder (development files)
and the libx265-dev_2.6-3_amd64 is the latest stable version.
To make sure you are up to date, open a terminal and type
sudo apt-get update && sudo apt-get install libx265-dev

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

Ubuntu and the circle of friends logo are trade marks of Canonical Limited and are used under licence.

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Источник

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.

Источник

How do you find what version of libstdc++ library is installed on your linux machine?

I found the following command: strings /usr/lib/libstdc++.so.6 | grep GLIBC from here. It seems to work but this is an ad-hoc/heuristic method. Is there a specific command that can be used to query the library version of C++? Or is the method I found the accepted method?

4 Answers 4

To find which library is being used you could run

 $ /sbin/ldconfig -p | grep stdc++ libstdc++.so.6 (libc6) => /usr/lib/libstdc++.so.6 

The list of compatible versions for libstdc++ version 3.4.0 and above is provided by

 $ strings /usr/lib/libstdc++.so.6 | grep LIBCXX GLIBCXX_3.4 GLIBCXX_3.4.1 GLIBCXX_3.4.2 . 

For earlier versions the symbol GLIBCPP is defined.

The date stamp of the library is defined in a macro __GLIBCXX__ or __GLIBCPP__ depending on the version:

// libdatestamp.cxx #include int main(int argc, char* argv[]) < #ifdef __GLIBCPP__ std::printf("GLIBCPP: %d\n",__GLIBCPP__); #endif #ifdef __GLIBCXX__ std::printf("GLIBCXX: %d\n",__GLIBCXX__); #endif return 0; >$ g++ libdatestamp.cxx -o libdatestamp $ ./libdatestamp GLIBCXX: 20101208 

The table of datestamps of libstdc++ versions is listed in the documentation:

The datestamps are almost entirely useless, I don’t know why we bother keeping them or documenting them. For example, the date for GCC 4.6.3 is later than 4.7.0, but 4.7.0 has more features, so what use is knowing the date it was released?

It can be short form to strings $(/sbin/ldconfig -p | grep stdc++|awk -F’=>’ ‘‘)|grep LIBCXX

What exactly do you want to know?

The shared library soname? That’s part of the filename, libstdc++.so.6 , or shown by readelf -d /usr/lib64/libstdc++.so.6 | grep soname .

The minor revision number? You should be able to get that by simply checking what the symlink points to:

$ ls -l /usr/lib/libstdc++.so.6 lrwxrwxrwx. 1 root root 19 Mar 23 09:43 /usr/lib/libstdc++.so.6 -> libstdc++.so.6.0.16 

That tells you it’s 6.0.16, which is the 16th revision of the libstdc++.so.6 version, which corresponds to the GLIBCXX_3.4.16 symbol versions.

Or do you mean the release it comes from? It’s part of GCC so it’s the same version as GCC, so unless you’ve screwed up your system by installing unmatched versions of g++ and libstdc++.so you can get that from:

Or, on most distros, you can just ask the package manager. On my Fedora host that’s

$ rpm -q libstdc++ libstdc++-4.6.3-2.fc16.x86_64 libstdc++-4.6.3-2.fc16.i686 

As other answers have said, you can map releases to library versions by checking the ABI docs

«ask the package manager» is a good approach. On Debian 9 I run apt list libstdc++6 and get libstdc++6/oldoldstable,oldoldstable,now 6.3.0-18+deb9u1 amd64 [installed]

The mechanism I tend to use is a combination of readelf -V to dump the .gnu.version information from libstdc++, and then a lookup table that matches the largest GLIBCXX_ value extracted.

readelf -sV /usr/lib/libstdc++.so.6 | sed -n 's/.*@@GLIBCXX_//p' | sort -u -V | tail -1 

if your version of sort is too old to have the -V option (which sorts by version number) then you can use:

tr '.' ' ' | sort -nu -t ' ' -k 1 -k 2 -k 3 -k 4 | tr ' ' '.' 

instead of the sort -u -V , to sort by up to 4 version digits.

In general, matching the ABI version should be good enough.

If you’re trying to track down the libstdc++.so. , though, you can use a little bash like:

file=/usr/lib/libstdc++.so.6 while [ -h $file ]; do file=$(ls -l $file | sed -n 's/.*-> //p'); done echo $

so for my system this yielded 6.0.10 .

If, however, you’re trying to get a binary that was compiled on systemX to work on systemY, then these sorts of things will only get you so far. In those cases, carrying along a copy of the libstdc++.so that was used for the application, and then having a run script that does an:

export LD_LIBRARY_PATH= exec application.bin "$@" 

generally works around the issue of the .so that is on the box being incompatible with the version from the application. For more extreme differences in environment, I tend to just add all the dependent libraries until the application works properly. This is the linux equivalent of working around what, for windows, would be considered dll hell.

Источник

Viewing Linux Library / Executable version info

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:

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

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)

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

test@ubuntukrb12:~# ls --version ls (GNU coreutils) 8.13 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later . 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 Architecture: amd64 Uncompressed Size: 306 k Depends: libbind9-80, libc6 (>= 2.14), libdns81, libisc83, libisccc80, libisccfg82 Conflicts: bind9utils Replaces: bind9 ( 

Источник