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
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.
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
/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 | 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