How can shared object files be linked with other shared or regular objects to produce new object files?

Viewed 473

I'm reading the ELF specification here: https://refspecs.linuxbase.org/elf/elf.pdf

On page 15:

A shared object file holds code and data suitable for linking in two contexts. First, the link editor may process it with other relocatable and shared object files to create another object file. Second, the dynamic linker combines it with an executable file and other shared objects to create a process image.

I've seen multiple questions raised by others on SO asking about statically linking shared objects, which seems to be what this paragraph is suggesting, and yet the common answer seems to usually be that doing this is not possible.

Either I'm misunderstanding what this is saying (probably), or there isn't a consensus about what can be done with shared objects.

What does this paragraph mean?

1 Answers

Either I'm misunderstanding what this is saying (probably)

What the paragraph appears to try to say: there are two contexts in which a shared library may be used:

  1. By static linker (aka link editor), to build a new shared library or an executable out of relocatable objects (i.e. build a new ET_DYN or ET_EXEC from ET_RELs), and
  2. By dynamic linker to build a process image.

Note that the new shared library built in case 1 does not include the existing shared library in it. The existing library is needed only so the static linker knows how the new shared library (or executable) should reference symbols from the existing library.

Most of the questions I've seen (and probably the ones you are referring to) are "how do I put existing libfoo.so into a new libbar.so?", and that is in fact impossible.

Update:

I'm still not sure I understand. Is #1 the initial creation of the shared library?

Yes: creation of a new shared library or an executable.

Because then an executable also has two contexts: 1) The static linker creating the executable out of relocatable objects and 2) By use of the loader to build a process image.

That is true, but only for dynamically linked executables. Fully-static executables do not involve the loader at all.

I could say a similar thing for relocatable objects as well

Not really: relocatable objects do not normally participate in process image building (there are exceptions, but they are really special and odd-ball), and they are certainly not handled by the dynamic linker (loader).

For all practical purposes, relocatable objects are only useful as building blocks for a shared library or an executable.

Related