3 ms·
> But doesn't static linking JUST link in the used features of the linked libs? No, not if it works like it does in C and C++. Lisp used to do that, back when
by cbd1984 11y ago
> But doesn't static linking JUST link in the used features of the linked libs?
No, not if it works like it does in C and C++.
Lisp used to do that, back when Symbolics still existed; it was called tree-shaking, as in "shake the call graph tree to see what falls out". The main function calls functions FOO, BAR, BAZ, which call FROTZ and QUUX, which call... and remove everything not in that tree.
Of course, this gets to be equivalent to solving the Halting Problem the moment the EVAL function is called, so if the tree-shaker found any mention of EVAL anywhere in the code (probably after it had removed the provably dead code) it punted and linked in the whole Lisp runtime. It was the only viable solution, really, especially given how creative Lispers can get...
- adrusi 11y agoIn C and C++ you can conservatively eliminate unused code for statically linked libraries using --gc-sections and -fdata-sections. Go uses the Plan9 compiler architecture, which means that its linker knows more about the code and is responsible for more optimizations than its Unix equivalent, so it quite effectively eliminates dead code. Of course, libraries are often highly coupled within themselves, so not much code can be eliminated, and then they might pull in additional dependencies, etc., etc.
- cbd1984 11y agoInteresting. I didn't realize there had been any substantive new work done on linkers in decades.
- lispm 11y agoLisp still does that. The commercial Lisps Allegro CL and LispWorks have that as a part of their respective delivery toolkit. See for example the LispWorks documentation: 4.6 How Delivery makes an image smaller, http://www.lispworks.com/documentation/lw70/DV/html/delivery-22.htm#pgfId-854332 http://www.lispworks.com/documentation/lw70/DV/html/delivery...