6 ms·

Static linking avoids this overhead right?

• richardwhiuk 8y ago
  Increases memory usage, disk space, patch requirements and load time due to lack of shared library caching
• saagarjha 8y ago
  Yes, at the cost of a bloated binary size.
  • gaius 8y ago
    But what if you link in just the functions you need, vs having the enormity of Library X on your disk that the package manager put there because it can’t know what you actually use/need?
    • saagarjha 8y ago
      Sure, but generally Library X is already on your system because someone else needs it. So why not use it if it's there?
      • gaius 8y ago
        Maybe you want it in a container with minimum dependency
• nneonneo 8y ago
  Yes, a statically-linked binary will have all internal references resolved by the linker. If PIE is disabled, the addresses will all be fixed, which makes exploiting such a binary much easier. Glibc has only just added support for static PIE executables (in Feb of this year), and I'm not sure what the implementation is - whether it relocates all the references in the binary (increased memory usage), or uses a PLT/GOT approach to support relocations (increased runtime overhead).
  • brandmeyer 8y ago
    Depending on the linkage, function calls internal to the library can use ordinary PC-relative function calls instead of fully indirect function calls. So you get the low per-call cost, but pay a higher per-process cost in memory consumption.
    • BeeOnRope 8y ago
      Exactly. The cost of indirect jumps isn't implied by position independent (PIE/PIC) code alone, but by PIE/PIC combined with jumps across separately loadable segments. For jumps _within_ a segment you can just use a direct relative call which is the fastest type of call and doesn't require any load-time fixup ever. Of course then there is also the consideration of symbol interposition: if you want to support that even _within_ a statically linked thing (usually something other than the main executable), then you need a GOT-like thing, but not necessarily a PLT-like thing.
  • tannhaeuser 8y ago
    Does it necessarily use more memory though? Eg. code is usually read-only hence can be shared by multiple processes (for apps that create many invocations of the same executable).
    • saagarjha 8y ago
      You'd have to check every page to see if you already have a read-only copy in memory though, right?
• mehrdadn 8y ago
  Not quite, necessarily. It means another program can't share the same DLL as that one. So you might well end up using more memory that way.
  • jcelerier 8y ago
    But you can use LTO with more libs which may reduce your overall binary size.