Question

I’m using GCC 4.7 to compile a large app that consists of only one C++ source file, so there’s only one compilation unit, but it includes many long headers. The final optimized executable, myapp, is 40MB, but the optimized object file, myapp.o, is 101MB. How is it possible that the object file is bigger than the binary?

I ran “nm -AC myapp” and “nm -AC myapp.o” to see if one had dramatically more symbols than the other — there’s about 1000 symbols difference but they’re mostly things you would expect like the binary adding the symbols for standard exception handling and static init.

I then ran ‘readelf -a’ on both and got this for myapp.o:

Number of section headers:         29186
Section header string table index: 29183

But this for myapp:

Number of section headers:         40
Section header string table index: 37

So I’m guessing that accounts for the size difference, but I don’t actually know what this means, or how to get the size down. Am I barking up the wrong tree? My goal is to get the compile time for myapp down, but first I need to understand what’s wrong. If symbols were the problem I could look into using GCC’s -fvisibility=hidden option, but I’d expect more differences in nm if that were the problem.

Edit: Additional info, everything not defined in my source file is from dynamically linked libs.

Answer 1

Object files contain lots of extra info to allow the seperate files to be linked together. In addition much code may be optimized out once all object files in the project are linked together. (example, uncalled library routines may be included in the object file, but are not needed once the compiler knows which routines wil actually be used in the final binary.