What C library version does my system use?
Why not try it and see. I don’t know if the version tells you everything; what about patches? Or are distrubutions careful about altering the ABI? Isn’t the issue whether the exported symbols are resolved, or something like that?
Nice answers, but no one addresses how to do this on a Mac, where there is no ldd . I’m not sure if otool —version can be regarded as giving the same information.
@dubiousjim Someone could; just not me, because I’m not a Mac user. Around here you might have to ask specifically about that — part of the issue is perhaps people generally don’t use plain C much on OSX? But I’m sure there will be a regular who knows. You could also post a link to this in chat and see what happens, but probably a new, more specific question would be better.
6 Answers 6
GNU/Linux systems usually use either glibc (Fedora/Redhat family, Arch) or its close cousin, eglibc (Debian/Ubuntu family); since eglibc is now being merged back into glibc (see EGLIBC 2.19 Branch Created under «News»), in the near future they will all be glibc again.
The easiest way to check the exact version is to ask ldd , which ships with the C library.
> ldd --version ldd (GNU libc) 2.18 On Raspbian (Debian 7 port for ARMv6 Broadcom SoC):
> ldd --version ldd (Debian EGLIBC 2.13-38+rpi2) 2.13 If for whatever reason you have mixed and matched some parts or otherwise aren’t sure about ldd , you can query the C library directly.
> whereis libc.so libc: /usr/lib64/libc.a /usr/lib64/libc.so /usr/share/man/man7/libc.7.gz None of those is executable but they provide a clue about where to find one.
> $(find /usr/lib64/ -executable -name "*libc.so*") --version GNU C Library (GNU libc) stable release version 2.18, by Roland McGrath et al. However, it is not necessarily so easy, because the C library does not have to reside somewhere whereis can find it.
> whereis libc.so libc: /usr/share/man/man7/libc.7.gz Unfortunately, the man page does not provide a version number. ldd still comes in handy, since any working, dynamically linked executable on the system (e.g., almost everything in /usr/bin ) will link to the C library.
> ldd /usr/bin/touch /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so (0xb6eed000) librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb6ed0000) libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6da1000) /lib/ld-linux-armhf.so.3 (0xb6efb000) libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6d82000) libc.so.6 is on the third line.
> /lib/arm-linux-gnueabihf/libc.so.6 --version GNU C Library (Debian EGLIBC 2.13-38+rpi2) stable release version 2.13, by Roland McGrath et al. @ElliottFrisch It was intended to apply to GNU/Linux, as in, «normal GNU/Linux» (adjective, noun), since there could be (are, I’m sure) systems which do not use (e)glibc but do use the rest of the GNU stack (bash, binutils, etc.). I would consider those «unusual» GNU/Linux systems. But I’ve removed the «normal » and changed it to «GNU/Linux systems usually use. «. Note I intentionally left the question open WRT OS specifics (there is no linux or GNU or glibc tag), so if you want to add an answer regarding any system appropriate to U&L, please do.
After I found it like you showed and I queried the version, it also printed available extensions! (in my case stubs, crypt, libidn, native threads and bind) and referred to ABI: libc ABIs: UNIQUE IFUNC.
Debian uses /lib/`uname -m`* path. So portable way would be: find /lib/`uname -m`* /usr/lib* -executable -name «*libc.so*» | xargs —version . Thanks for nice explanation.
A system isn’t actually limited to one C library. Most, though, primarily use only one, which will also be the one the default compiler uses. And since you’re downloading source code to compile, that’s the one you’re concerned with.
Start with a trivial program:
compile it using the compiler you’re going to use for the source code, then use ldd to find out where the C library is:
$ ldd ./libc-test linux-vdso.so.1 (0x00007fff2e5fe000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8c8ad98000) /lib64/ld-linux-x86-64.so.2 (0x00007f8c8b171000) You now have the path to the C library. You could look this up in your package manager to find the package (e.g., dpkg -S /lib/x86_64-linux-gnu/libc.so.6 or rpm -q -f /lib/x86_64-linux-gnu/libc.so.6 ).
At least in the case of eglibc/glibc, you can run it:
$ /lib/x86_64-linux-gnu/libc.so.6 GNU C Library (Debian EGLIBC 2.18-4) stable release version 2.18, by Roland McGrath et al. Copyright (C) 2013 Free Software Foundation, Inc. ⋮ Finally, you could see if you can get clues from objdump -p /lib/x86_64-linux-gnu/libc.so.6 , by looking in the version definitions section:
Version definitions: 1 0x01 0x0865f4e6 libc.so.6 2 0x00 0x09691a75 GLIBC_2.2.5 3 0x00 0x09691a76 GLIBC_2.2.6 ⋮ 21 0x00 0x06969197 GLIBC_2.17 GLIBC_2.16 22 0x00 0x06969198 GLIBC_2.18 GLIBC_2.17 23 0x00 0x0963cf85 GLIBC_PRIVATE GLIBC_2.18 Note how the GLIBC_2.18 symbol has the most recent version number among the symbols listed, and the library version is indeed 2.18. It’s eglibc, though (it aims to be binary-compatible with glibc 2.18, so it uses the same symbol versions).
You could also attempt to use strings to find out something about it. You’ll want to specify a longer minimal length ( -n ), or use grep to search for something:
$ strings /lib/x86_64-linux-gnu/libc.so.6 | grep 'version 5' $ strings /lib/x86_64-linux-gnu/libc.so.6 | grep -iC1 'copyright' both work for this eglibc.
NOTE: The Debian package utility dpkg-shlibdeps uses objdump under the hood, along with stored symbol information in Debian library packages to determine the minimum versions of dependencies required by binary Debian packages at build time. Basically, it looks at the symbols exported by the binary Debian package, and then finds the minimum versions of the libraries that contain those symbols.
The obvious answer, though not the most comprehensive, is to check your package manager, e.g
rpm -qi glibc dpkg -l libc6 (Sadly, glibc doesn’t have a pkconfig .pc file, so pkgconfig —modversion glibc is a non-runner.) See also @Gnouc’s excellent getconf suggestion.
The simplest case, with gcc+glibc, and the one I mostly use first is to just execute libc.so , as outlined in some of the other answers here. There’s no need to pass any arguments, it outputs its version by default. This works back as far as glibc-2.1 (glibc-2.0 seg-faults, though way back then you could check the (now retired) glibcbug script to confirm the version). This method also works with recent (>0.9.15) versions of musl-libc (which just went 1.0 today, March 20th). It does not work with uClibc, it segfaults.
One simple way to tell exactly what your gcc is going to do is compile:
#include #include int main(int argc, char *argv[])
(with glibc, includes which defines the relevant GLIBC macros, you need for the function declarations.)
This catches more complex cases (multiple libc’s, and/or multiple compilers), assuming you’re using the right compiler (and flags) of course. (I suspect it won’t distinguish between eglibc and glibc proper though.)
If you are certain you are using glibc (or eglibc) then ld will also confirm the version (sorry, this is not correct).
If __GNU_LIBRARY__ is not defined you will get errors, then it’s time for plan B.
gcc -dumpmachine may help, e.g. for uclibc it has a -uclibc suffix, as may gcc -dumpspecs | grep dynamic-linker . This also may imply the ABI.
gcc -print-file-name=libc.so will tell you what file the compiler will use for » -lc «, this is almost certainly a linker-script within your gcc installation, which you can read it as plain text. That will show the exact path to libc.so . This will also work if you’re passing flags like -m32 or -m64 .
In the event you’re using uclibc (as used by OpenWRT and more), it defines __UCLIBC_MAJOR__ , __UCLIBC_MINOR__ and __UCLIBC_SUBLEVEL__ as well as __UCLIBC__ in , so it’s easily detected using a minor variation on the above C code snippet. In the interest of compatibility, uClibc may also define the GNU/GLIBC macros as used above, it currently pretends to be glibc-2.2. It does not currently implement the gnu_get_libc_X() functions, but it does implement getconf which may also mislead (I suspect it returns an empty answer for getconf GNU_LIBC_VERSION , my build env is sulking today so I cannot confirm.)
In the unlikely event you’re using dietlibc, running diet -v will display the version.
(FWIW, over several years with software using autoconf I’ve had more problems with unchecked-for gcc and g++ requirements than with checked-for glibc features.)
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.
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.