Você está misturando as definições de um arquivo binário e um arquivo executável (binário).
O livro está certo de mencionar /etc/ld.so.cache
é um arquivo binário (um arquivo de dados).
Como você pode ver executando file /etc/ld.so.cache
$ file /etc/ld.so.cache
/etc/ld.so.cache: data
De 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.
De man ldconfig
/etc/ld.so.cache
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.
Além disso, /etc/ld.so.cache
é regenerado ao executar ldconfig
. Veja Relação entre ldconfig e ld.so.cache
Verificação dupla é de fato uma lista de arquivos de biblioteca:
$ strings /etc/ld.so.cache | head -5
ld.so-1.7.0
glibc-ld.so.cache1.1
libz.so.1
/lib/x86_64-linux-gnu/libz.so.1
libxtables.so.7
Ou novamente, usando 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