5 ms·

> On average, dynamically linked executables use only 4.6% of the symbols on offer from their dependencies. That's correct, but also very misleading and leads

> On average, dynamically linked executables use only 4.6% of the symbols on offer from their dependencies. That's correct, but also very misleading and leads to the wrong conclusion. The dynamically linked library has references to itself, externally visible or not. It would be wrong to claim that Application.run(); only uses a single symbol of a library. > A good linker will remove unused symbols. With LTO or -f{function,data}-secions + --gc-sections any linker will do. Without those options no linker is allowed to. I believe that this the reason why static libraries are usually shipped as separate object files (.o) within ar archives (.a), as those were only linked in on demand.

iforgotpassword 6y ago
> I believe that this the reason why static libraries are usually shipped as separate object files (.o) within ar archives (.a), as those were only linked in on demand. Yep. One function per C/obj file for smallest static binary possible.
- arcticbull 6y ago
  Can't you achieve the same result with -ffunction-sections?
  - loeg 6y ago
    Yes. And its twin, -fdata-sections.
  - iforgotpassword 6y ago
    Yes but that's modern fancy stuff. :-)
  - pjmlp 6y ago
    Yes, on the compilers that offer it.
Someone 6y ago
Also, how many symbols it uses is relevant for the time linking takes, but not for memory usage. Worse, I think it would have been easier to measure the size in bytes of binaries, or, with a bit more effort, resident memory size.
ndesaulniers 6y ago
> On average, dynamically linked executables use only 4.6% of the symbols on offer from their dependencies. For more on this, I highly recommend these two posts, which show how modern symbol tables optimize for symbols NOT being found within a given shared object via the use of bloom filters. 1. https://flapenguin.me/elf-dt-hash https://flapenguin.me/elf-dt-hash 2. https://flapenguin.me/elf-dt-gnu-hash https://flapenguin.me/elf-dt-gnu-hash
- saagarjha 6y ago
  This was a great look at something that in hindsight understand must exist but was totally unaware of. Thanks!
account42 6y ago
> > A good linker will remove unused symbols. Additionally, a linker not be able to remove symbols that are unused at runtime but are still (transtively) referenced statically. For memory mapped dynamic libaries those code pages will not be loaded unless needed. For example, statically linking libstdc++ for any C++ program which uses iostreams (or anything else infected with std::locale) will mean including code to format and parse e.g. monetary amounts even if your program never uses this functionality.

iforgotpassword 6y ago

> I believe that this the reason why static libraries are usually shipped as separate object files (.o) within ar archives (.a), as those were only linked in on demand. Yep. One function per C/obj file for smallest static binary possible.

arcticbull 6y ago
Can't you achieve the same result with -ffunction-sections?
- loeg 6y ago
  Yes. And its twin, -fdata-sections.
- iforgotpassword 6y ago
  Yes but that's modern fancy stuff. :-)
- pjmlp 6y ago
  Yes, on the compilers that offer it.

Someone 6y ago

Also, how many symbols it uses is relevant for the time linking takes, but not for memory usage. Worse, I think it would have been easier to measure the size in bytes of binaries, or, with a bit more effort, resident memory size.

ndesaulniers 6y ago

> On average, dynamically linked executables use only 4.6% of the symbols on offer from their dependencies. For more on this, I highly recommend these two posts, which show how modern symbol tables optimize for symbols NOT being found within a given shared object via the use of bloom filters. 1. https://flapenguin.me/elf-dt-hash https://flapenguin.me/elf-dt-hash 2. https://flapenguin.me/elf-dt-gnu-hash https://flapenguin.me/elf-dt-gnu-hash

saagarjha 6y ago
This was a great look at something that in hindsight understand must exist but was totally unaware of. Thanks!

account42 6y ago

> > A good linker will remove unused symbols. Additionally, a linker not be able to remove symbols that are unused at runtime but are still (transtively) referenced statically. For memory mapped dynamic libaries those code pages will not be loaded unless needed. For example, statically linking libstdc++ for any C++ program which uses iostreams (or anything else infected with std::locale) will mean including code to format and parse e.g. monetary amounts even if your program never uses this functionality.