Quuxplusone
commented
6 years ago This might be better as a discussion on the mailing list than a bug as such.
You mentioned it has "become enormous" - do you have a revision at which it was
substantially smaller?
Are you sure you're getting a shared library build? Not many people use them (&
I don't) so I could be wrong, but yes, I'd expect smaller final binaries if
they just reference a bunch of shared libraries.
Clang's debug info is substantially smaller than GCC's, so you could try
building your Clang with Clang rather than with GCC
You could also try using Split DWARF (there's a flag for it in CMake -
LLVM_USE_SPLIT_DWARF) which avoids having the debug info in the .o files and
avoids copying it into the final executable so may reduce the overall disk
usage footprint of a build.
Windows uses separate debug info (somewhat like the Split DWARF mentioned
above) files (PDBs) so its binaries are smaller but the actual debug info/total
build disk usage footpring may still be large. Unix/DWARF debugging has
historically been in the object file and linked into the final executable -
perhaps for ease of generation and distribution (if you send a debug-having
binary to somewhere, you have the debug info - it's not in separate files you
have to handle in addition)
This may be something to do with any number of things other than CMake, but that's what I'm generating the build scripts with so I'm putting this here for now... the size of llvm binaries has somehow become enormous on Ubuntu. Here's Clang, for example:
-rwxr-xr-x 1 root root 1824M Dec 3 22:42 /usr/local/bin/clang-6.0
LLVM binaries have never been exactly small in debug mode, but this looks new to me. Is there some type of dwarf generation issue or flag I can use to prevent this? As of now make followed by make install on an 80GB VM disk (which had always been enough for quick builds and is nearly unused otherwise) almost filled the disk starting from having 70GB free. strip -g on clang-6.0 reduced this size to:
-rwxr-xr-x 1 root root 299M Dec 3 23:29 /usr/local/bin/clang-6.0
Which is still rather enormous although acceptable, but defeats the purpose of a debug build in the first place. I thought I built this as a shared library version, but it seems to just link in all the debug info from the static libs anyway which also defeats the purpose of that.
Is there some flag or trick I'm missing to keep the debug info from inflating size this much? Can it be produced externally with some flag or another? Build was with a relatively recent GCC, it built debug by default with make -j8. Those file sizes also limit the ability to run VM disks from regular hard drives because the disk activity is the limiting factor, hence the small VM disk size on a fast SSD to keep up.
Is this even normal?
I'm marking as an enhancement because if there's something we can add to CMake to help stop this behavior? Am I missing a flag somewhere? My windows release build ended up with a 50M clang++.exe with the same targets (ALL), and RTTI and EH turned on in addition to that, so this seems to be something more linux specific or I'm forgetting something.