- Is there a way to identify version of c/c++ library?
- 5 Answers 5
- Viewing Linux Library / Executable version info
- 4 Answers 4
- You must log in to answer this question.
- Related
- Hot Network Questions
- Subscribe to RSS
- How do you find what version of libstdc++ library is installed on your linux machine?
- 4 Answers 4
Is there a way to identify version of c/c++ library?
For example, how to get the version of /usr/lib/libz.a? It will be great if other useful information such as compiler/arch etc. can be fetched. The reason I want to know this is that gcc always say it ignored the libz I offered in command line when I compile my program and linked with specific versioned libz. gcc think the /usr/lib/libz.a is a proper one.
On linux like systems the version is in the name and then symbolic links are used to get the compiler to embed the version named of a shared lib into an executable.
5 Answers 5
C libraries do not have on their own a versioning system. At best, there is a symbol in the library that tells it.
Linux/Unix Elf-specific answer:
Library archives with the .a extension are an ar archive (a little like a tar or an uncompressed zip , modulo a few features), which contains nothing more than the original object files packed together. There is rarely any extra metadata in these files. You are unlikely to find any information about the compiler unless it stored that information in the original .o files. You can view the contents of an archive with the ar command:
Shared object files ( .so ) and executables are a different story. Using the readelf and dumpelf commands from elfutils, you can extract metadata about the shared object, including its canonical name, what libc it was built for, which toolchain built it, and so on. See man readelf and related pages for details.
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 ( 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.
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'=>' '
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.