|
|
|
|
|
by drwells
2921 days ago
|
|
At least one C++ library that I rely on (that produces an incredible number of template instantiations in the object files) ultimately results in a 2 GB shared object file for the debug version (generating DWARF info for 300,000+ objects takes up a lot of space). The test suite for this project compiles and runs about 5,000 executables that link, in some way, to that giant shared object library. Statically linking the test suite would consume on the order of terabytes (I am not sure the exact number; I have never tried) of disk space which just is not feasible for a workstation, so dynamic linking is the only reasonable option. Dynamic linking also makes testing easier since I do not have to recompile tests as often. That said, DLL hell is definitely real (as anyone who has ever used windows knows). Things are generally better (though not perfect) with OSs like Debian where dependencies are centrally managed across the whole system. In general, doing C++ development, I have found it advantageous to dynamically link: recompiling one library does not necessitate recompiling everything that depends on it. |
|
I read complaints like this a lot. Have you ever tried using -ffunction-sections -fdata-sections and --gc-sections as in :https://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vla...
I find static linking to take up far less disk space when done properly, but I keep seeing comments like this.