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
/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.
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
ld.so-1.7.0
glibc-ld.so.cache1.1
libz.so.1
/lib/x86_64-linux-gnu/libz.so.1
libxtables.so.7
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
