5
$ file /lib/ld-linux.so.2
/lib/ld-linux.so.2: symbolic link to i386-linux-gnu/ld-2.27.so
$ readlink -f /lib/ld-linux.so.2
/lib/i386-linux-gnu/ld-2.27.so
$ file /lib/i386-linux-gnu/ld-2.27.so
/lib/i386-linux-gnu/ld-2.27.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=7a59ed1836f27b66ffd391d656da6435055f02f8, stripped

So is ld-2.27.so a shared library?

It is said to be a dynamic linker/loader and mentioned in section 8 of man. So is it an executable?

If yes, why is it named like a shared library as *.so?

If no, how shall I understand it is like an executable, for being a dynamic linker/loader and mentioned in section 8 of man?

Thanks.

Stephen Kitt
  • 434,908
Tim
  • 101,790

1 Answers1

10

It is both, which is perfectly valid.

The ld.so-style naming scheme is largely historical; the first dynamic linker in this style was SunOS 4’s, which was named ld.so (I have its history somewhere, I’ll clarify this once I’ve found it). But there are valid reasons for it to be named like a shared library rather than an executable, including:

  • it exists to serve executables, like shared libraries (it has no purpose without executables to run);
  • it is a shared ELF object, but it doesn’t require an interpreter (it has no .interp entry); this is typical of libraries (shared, or rather dynamically-linked, executables always require an interpreter; otherwise they’re statically-linked).

The distinction between executables and libraries is somewhat fluid in ELF; any ELF object with an entry point and/or an interpreter can be an executable, regardless of its other properties.

Stephen Kitt
  • 434,908
  • Did you happen to find that naming history? – ilkkachu Jul 11 '18 at 12:02
  • @ilkkachu not yet... – Stephen Kitt Jul 11 '18 at 12:11
  • (1) "shared executables always require an interpreter; otherwise they’re static, not dynamic". Do you mean "shared libraries always require an interpreter; otherwise they’re static, not dynamic"? What makes an ELF object file become a shared library file? (Does having .interp entry make an ELF object file become a shared library file? ) (2) What makes an ELF object file become a static library file? (Or is a static library file not an ELF object file, but an archive of relocatable object files?) – Tim Sep 27 '20 at 20:58
  • (1) I mean what I wrote. Executables have interpreters (if they’re dynamically linked), not libraries. Some libraries are also executable files, e.g. libc.so.6 (see the link in the first paragraph). An ELF object file is a shared library if its type is ET_DYN. (2) A static library is an archive of relocatable object files. – Stephen Kitt Sep 27 '20 at 21:20
  • Thanks. "it doesn’t require an interpreter (it has no .interp entry); this is typical of libraries (shared executables always require an interpreter; otherwise they’re static, not dynamic)." What does "this is typical of libraries" mean then? Do you mean a library (a shared library) must have or typically has .interp entry? – Tim Sep 27 '20 at 21:26
  • It is typical for shared libraries not to require an interpreter. What is typical is the entire first part: “it doesn’t require an interpreter (it has no .interp entry)”. – Stephen Kitt Sep 27 '20 at 21:29
  • (1) "Executables have interpreters (if they’re dynamically linked), not libraries. " Do executables which are not dynamically linked have .interp? Does any executable have both .interp and entry point? (2) "libraries are also executable files", for such files, are their ELF types ELF_DYN, not ELF_EXEC? So does "executable" here not mean that its ELF type is ELF_EXEC, but that it has .interp and entry point? – Tim Sep 28 '20 at 00:52
  • (1) Executables which are not dynamically-linked don’t have .interp. Executables always have an entry point. (2) I’ve answered this already. Libraries always have type ET_DYN. Executables can have type ET_EXEC or ET_DYN; they always have an entry point, and tjey have .interp if they are dynamically-linked. – Stephen Kitt Sep 28 '20 at 04:54