8

It's common practice to strip a symbol table from a dynamic library (.dll on Windows, .dylib on OSX, and .so on Linux/Solaris/BSD). This makes sense because it drastically reduces the file size of the library, often more than 75 percent.

However, this one question's been bugging me: A stripped library has no symbol table. If I write an executable that references a function in this library, how does the operating system's dynamic linker know where to locate the section of code in the stripped library when there's no symbol table to provide this information?

This question comprises both the situation where the library was stripped before the executable was linked at compile-time and the situation where the library was stripped after the executable was linked at compile-time.

Enlico
  • 23,259
  • 6
  • 48
  • 102
Leo Izen
  • 4,165
  • 7
  • 37
  • 56

1 Answers1

13

The symbols that are stripped when you run strip are the debugging symbols, not the names of actual exported symbols.

The dynamic symbols, the ones that the linker searches for, are still there, and can be listed by using the -D (Lists dynamic symbols) argument.

DusteD
  • 1,400
  • 10
  • 14
  • 1
    Then why does `nm` report "No Symbols"? – Leo Izen Nov 29 '13 at 15:03
  • 2
    @LeoIzen: Without any command line switches, `nm` will default to **NOT** printing the dynamic/export symbol table. `nm -a` or `nm -D` should rectify this issue. As discussed in the answer, you basically strip the non-exported symbols when you use `strip`. Anything that is exported, that is, that needs to be located dynamically within the library when it is linked at run-time is not stripped by this command. – Andon M. Coleman Nov 29 '13 at 22:25