13

I noticed something while doing find /bin -exec file {} \; :

the file command reports some entries in /bin are shared objects , while others as executables . For instance,

/bin/ntfsck:
ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=312d93fd0d8653e7236a61db2e67b93c63225a00, stripped

Same report for gawk

/usr/bin/gawk:
ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.24,
BuildID[sha1]=76bb13aac7e212164bd6e0d7b8a5d92db44543c9, stripped

In contrast file for /bin/echo is:

/bin/echo:
ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.24,
BuildID[sha1]=193e75fc13e9c4599e772b8d79125a5934cf601c, stripped

Essentially, I want to know what is the difference between executable files and shared object files.

13

Tl;dr

There's no difference, aside from the fact that a compiled executable might be linked against a shared object but not against an executable.


In general, there are two ways to compile1 an executable:

  • Using static linking: external libraries included in the source code are compiled and the compiled library (or object in the linker's perspective) is added to the executable itself;
  • Using dynamic linking: external libraries included in the source code are compiled but a link to the compiled library (or object in the linker's perspective) is added to the executable (and the compiled libraries / objects are loaded by the linker at run-time if needed);

There are advantages / disadvantages in using each of these methods, but that's not the point of the question;

  • /bin/ntfsck and /usr/bin/gawk are shared objects: this means that an executable might be compiled and then linked against them to use their functionalities;
  • /bin/echo is an executable: this means that an executable might not be compiled and then linked against it to use its functionalities;

So /bin/ntfsck and /usr/bin/gawk are technically compiled libraries (or objects in the linker's perspective), but, as one may have forsaw, nothing prevents a shared object from being run as an executable.

On a side note, notice also that file reports (for each of them):

dynamically linked (uses shared libs)

This means that each of them is dynamically linked to (and likely uses) other shared objects as well.


1. "Compile" intended in its broader acceptation, which includes preprocessing, compilation and linking.

  • 1
    dynamically linked to other shared objects , IN OS? or shared libraries in itself?! – Dr.jacky Dec 6 '15 at 9:12
  • @Mr.Hyde In the OS, more specifically in locations that must be preconfigured in the linker, so that the linker can load them at run-time if needed. See here, chapter 3.2. – kos Dec 6 '15 at 15:58
  • One can actually link against an executable using dlopen :D example – Adam Zahran Jul 17 at 0:46
3

Another difference is that executables have a defined entry point address offset, i.e., 0x08048000 for i386, 0x00400000 for x86 and 0x00010000 for arm.

A shared object file can be a library, but also an executable. When being an executable, there is no such offset. A shared object executable, so to say, is a positional independent executable (PIE) using address space layout randomization (ASLR). Thus, when looking at its /proc/pid/maps file, you will notice that the location of the loaded segments vary in each execution in contrast to standard executables.

The idea behind this feature is to add security to executables by hindering attackers from performing return-oriented programmings attacks. Many maintainers decided to build packages with PIE enabled as the default, e.g., since Fedora 23 or with Ubuntu 17.10.

  • Interesting answer. Lacks a few sources ( would be nice if you added a few links, especially for the entry point part ) but I searched a few stackoverflow questions about that. But definitely good answer. – Sergiy Kolodyazhnyy Sep 28 '17 at 17:46

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.