<p>This is more about compiler implementation than language design but when statically linking a library (e.g. in <a href="https://langdev.stackexchange.com/questions/2121/how-to-avoid-output-build-bloat-when-wanting-to-access-type-metadata-information#comment3523_2121">Swift</a>) the entire library is linked even if only a handful of the functions are actually used. This leads to bloat, but is there any reason to do this anyway? In the Swift example I doubt the <code>print()</code> function is 6MB in size, which means the entire library is included, rather than just the one needed function.</p>
<p>When statically linking library functions, why do many compilers/linkers not cull the unused library functions from the executable?</p>

<compilers>
Why link the entire static library rather than only the needed functions?
CC BY-SA 4.0
2023-07-07T00:00:43.020Z
I'll note that this is only due to type metadata, and not top-level functions. The size drops measurably if you remove the `print` call, because it strips the `print` function.
Bbrk24
<h3>The linker might not know how</h3>
<p>On mnay platforms a library is essentially a binary blob plus a symbol table.
The symbol table tells the compiler where to find each function etc.</p>
<p>What libraries do not always contain is information about which of those symbols are used by the functions <em>inside</em> the library.
The internal dependency graph is not stored.</p>
<p>There are <a href="https://en.wikipedia.org/wiki/Relocation_(computing)" rel="nofollow noreferrer">relocations</a> where addresses within a library are adjusted to compensate for where in the address space it is loaded.
But not all symbols need to be relocated
and internal calls are free to use relative addressing rather than absolute addressing.</p>
<p>So basically - the linker doesn't know what isn't used.</p>
<p>A clever compiler could store the full dependency graph and cull the unused stuff. This may not be so easy if, for example, you wish your libraries to follow the <a href="https://en.wikipedia.org/wiki/Executable_and_Linkable_Format" rel="nofollow noreferrer">ELF format</a> which is standard on most platforms.</p>

CC BY-SA 4.0
2023-07-07T01:14:10.723Z
2023-07-07T01:14:10.723Z
Bruce Adams
# Why link the entire static library rather than only the needed functions?
Posted by: username_0 on 2023-07-06
This is more about compiler implementation than language design but when statically linking a library (e.g. in [Swift](https://langdev.stackexchange.com/questions/2121/how-to-avoid-output-build-bloat-when-wanting-to-access-type-metadata-information#comment3523_2121)) the entire library is linked even if only a handful of the functions are actually used. This leads to bloat, but is there any reason to do this anyway? In the Swift example I doubt the `print()` function is 6MB in size, which means the entire library is included, rather than just the one needed function.

When statically linking library functions, why do many compilers/linkers not cull the unused library functions from the executable?
**Tags:** compilers
> **Comments:**
> **username_1**: I'll note that this is only due to type metadata, and not top-level functions. The size drops measurably if you remove the `print` call, because it strips the `print` function.  
---
## 1 answers
### Answer by username_2 on 2023-07-07. Score: 4 | Accepted answer
### The linker might not know how

On mnay platforms a library is essentially a binary blob plus a symbol table.
The symbol table tells the compiler where to find each function etc.

What libraries do not always contain is information about which of those symbols are used by the functions *inside* the library.
The internal dependency graph is not stored.

There are [relocations](https://en.wikipedia.org/wiki/Relocation_(computing)) where addresses within a library are adjusted to compensate for where in the address space it is loaded.
But not all symbols need to be relocated
and internal calls are free to use relative addressing rather than absolute addressing.

So basically - the linker doesn't know what isn't used.

A clever compiler could store the full dependency graph and cull the unused stuff. This may not be so easy if, for example, you wish your libraries to follow the [ELF format](https://en.wikipedia.org/wiki/Executable_and_Linkable_Format) which is standard on most platforms.
---
