Linux get library version

Benohead’s Software Blog

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:

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:

1. Check the version of the installed glibc rpm package
2. Check the version of the used libc.so file

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:

You can also find the libc.so file used with the following command:

So we now know that /lib64/libc.so.6 is being used and we just need to get it’s version:

If you want to determine the glibc version from C program and not from a shell script, you can just use something like this:

You can then compile it and execute it like this to get the glibc version:

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:

Источник

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?

3 Answers 3

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.

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.

Not the answer you’re looking for? Browse other questions tagged linux ubuntu version or ask your own 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 © 2021 Stack Exchange Inc; user contributions licensed under cc by-sa. rev 2021.10.8.40416

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 to control shared library version issue on Linux?

For example, I create a shared library named libXXX.so.0.0.0 with the soname as libXXX.so.0. So, do I need to create a symlink named libXXX.so.0 and let it points to the real shared library? Or do I just need to create a symlink named libXXX.so?

Besides, what if I update the library to libXXX.so.0.0.1?

If I install the shared library on the system library path, such /lib or /usr/lib , how to update the symlink? Using ldconfig?

If I install the shared library on current local folder, how to update the symlink?

BTW, how control the version issue in Makefile? I mean do I need to add some command such as ln -s or ldconfig?

1 Answer 1

Yes, create a symlink named libXXX.so.0 pointing to libXXX.so.0.0.0 .

If you want people to be able to construct programs that are linked against this library then also create a symlink named libXXX.so pointing to libXXX.so.0 .

The libXXX.so.0 symlink will be used by the program loader, because that’s the soname that the program will be looking for.

The libXXX.so symlink will be used by the linker when it is building a program, because by historical convention that’s how the linker works.

Besides, what if I update the library to libXXX.so.0.0.1?

Then you remake the libXXX.so.0 symlink so that it points to libXXX.so.0.0.1 . Nothing else needs to change. Since the libXXX.so symlink points to libXXX.so.0 it will automatically also point to the new library.

If you’re installing the new library by using some packaging system (RPM, . ) then use whatever feature the packaging system provides for managing symlinks. If you’re just using a script or a Makefile stanza then simply rm -f the old symlink and ln -s the new one.

Источник

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

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

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:

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

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:

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

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

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.

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

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:

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:

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

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?

4 Answers 4

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:

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.

Источник