I am currently studying for Comptia Linux+ exam and I am at the Shared Library chapter. Among all, it says that the /etc/ld.so.cache file is a binary file, but in my case it is not. It is a regular file, whose content I can easily view and fair enough it contains libraries locations.

ls -l /etc/ld.so.cache 
-rw-r--r--. 1 root root 154135 Feb 11 11:17 /etc/ld.so.cache

I've seen it in several materials that the cache file is a binary one and I am curious why this mismatch? Is that file's type distro-dependent? I am using Fedora Workstation 27


You are mixing up the definitions of a binary file, and an executable (binary) file.

The book is right mentioning /etc/ld.so.cache is a binary file (a data file).

As you can see running file /etc/ld.so.cache

$ file /etc/ld.so.cache 
/etc/ld.so.cache: data

From man ld.so:

When resolving shared object dependencies, the dynamic linker first inspects each dependency string to see if it contains a slash (this can occur if a shared object pathname containing slashes was specified at link time). If a slash is found, then the dependency string is interpreted as a (relative or absolute) pathname, and the shared object is loaded using that pathname.

If a shared object dependency does not contain a slash, then it is searched for in the following order:


  • From the cache file /etc/ld.so.cache, which contains a compiled list of candidate shared objects previously found in the augmented library path. If, however, the binary was linked with the -z nodeflib linker option, shared objects in the default paths are skipped. Shared objects installed in hardware capability directories (see below) are preferred to other shared objects.

From man ldconfig


File containing an ordered list of libraries found in the directories specified in /etc/ld.so.conf, as well as those found in /lib and /usr/lib.

Furthermore, /etc/ld.so.cache is regenerated upon running ldconfig. See Relationship between ldconfig and ld.so.cache

Double checking it is indeed a list of library files:

$ strings /etc/ld.so.cache | head -5

Or again, using ldconfig -p:

$ ldconfig -p | head -5
227 libs found in cache `/etc/ld.so.cache'
    libz.so.1 (libc6,x86-64) => /lib/x86_64-linux-gnu/libz.so.1
    libxtables.so.7 (libc6,x86-64) => /lib/libxtables.so.7
    libxml2.so.2 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libxml2.so.2
    libxml-security-c.so.17 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libxml-security-c.so.17
  • 2
    I see. I did not know that. Its my first time at stack exchange and its nice to see that you are a very helpful community. Thanks for the info – Ermir Bajraktari Feb 11 '18 at 11:32
  • 1
    @ErmirBajraktari Welcome to Unix&Linux Do not forget to accept the answer and keep using that user. – Rui F Ribeiro Feb 11 '18 at 11:38

It's a binary file because it contains binary data structures written to it using a program called ldconfig. The structure (Probably a Hashtable) is used to efficiently search and find the path of a shared object. The reason you see the pathes when you open the file in text mode is that because part of the structures contains strings or a table of strings (Path names) and that's all what the text editor can recognize as ASCII code strings (And therefore, show it on the screen).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.