An alternative to shared libraries (2008)

Re:An alternative to shared libraries (2008) by drwells on Monday June 25, 2018 @08:10PM (#17396938)

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.

[ Parent | on HN ]

Re:An alternative to shared libraries (2008) by abenedic on Monday June 25, 2018 @09:49PM (#17397317)

> 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

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.

[ Parent | on HN ]

Re:An alternative to shared libraries (2008) by ihalip on Tuesday June 26, 2018 @12:30PM (#17401971)

MSVC linker also supports removing unused functions/data from the output binary: https://msdn.microsoft.com/en-us/library/bxwfs976.aspx. These can be applied irrespective of compiler optimizations, so you should still be getting good PGD debug symbols.

Haven't tried it personally, but it's worth a try.

[ Parent | on HN ]

Re:An alternative to shared libraries (2008) by ebikelaw on Monday June 25, 2018 @08:36PM (#17397063)

Why don't you run your test suite with dynamic linking, then? I've certainly worked at large, successful companies with enormous C++ codebases where unoptimized tests are run with dynamic linking and production binaries optimized, stripped, and linked statically.

[ Parent | on HN ]