4 added 5 characters in body
source | link

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

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

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

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

The book is right mentioning that is a binary file (with data). 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

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
3 added 217 characters in body
source | link

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

The book is right mentioning that is a binary file (with data). 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

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

The book is right mentioning that is a binary file (with data). 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

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

The book is right mentioning that is a binary file (with data). 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
2 added 199 characters in body
source | link

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

The book is right mentioning that is a binary file (with data). 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

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

The book is right mentioning that is a binary file (with data). 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.

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

The book is right mentioning that is a binary file (with data). 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

1
source | link