If the same code is built at different times w/gcc, the resulting binary will have different contents. OK, I'm not wild about that, but that's what it is.
However, I've recently run into a situation where the same code, built with the same version of gcc, is generating a binary with a different size than a prior build (by about 1900 bytes).
Does anyone have any idea what may be causing either of these situations? Is this some kind of ELF issue? Are there any tools out there (other than ldd) that can be used to dump contents of binaries to see what exactly is different?
Thanks in advance.
I've managed to sort things out, at least to my satisfaction, and wanted to pass along what I've found.
Using readelf, (readelf -a -W ) I created a report listing contents of both builds and compared them (using Beyond Compare). This showed that a couple of extra symbols were getting pulled in from boost libs.
Lo and behold, we were in fact building against a different version of a dependent library and didn't realize it. No harm done in this case, but it's good to know what's going into your executable.
Thanks to all for the thoughtful replies.
objdump is probably the program you are looking for to dump the contents of binaries.
objdump -h will show you the sections and their sizes, so you should be able to see where the size change is happening and then drill down further to see why.
A replicable example would help:
- Do you use other external libraries?
- Do you link statically or dynamically?
- Did you change flags like -O or -s ?
This has been sort of been asked before, and the answer is that the internal state of the compiler may well be different on different compiler runs, which can result in different code been emitted and thus having different size.
The DEC VMS compilers used to do this too. The reason is that the optimizer could do a better job the more free RAM it had to work with. Obviously it is very difficult to have the exact same amount of free RAM available every time you compile.
I remember at the time some people were appalled by this. This was particularly the case for folks who liked to check for source changes by diff-ing the resulting binaries. My advice then as now is to get over it. Sources you can "diff". For binaries the only guarantee is that both executables compiled from the same source files will do what you told them to do.
In addition to the compiler you need to check the standard libraries you link against. Check their version and verify they have not changed.
One possible reason for a difference in size between otherwise identical builds is that there can be variable-sized information stored in the binary. Some examples:
- the compiler may be putting path/name information about the files invoved in the compilation, either for debugging information or due to the use of the
__FILE__macro. It's possible that it might do this for it's own purposes that have nothing to do with either of those things. If the build occurs on different machines with even a slightly different directory structure, this can account for differences in the binary. - similarly for the date/time of the build, though I'd expect that these would find their way into the binary much less often (but what do I know?). If this were a contributing factor, you'd see different sized out even from identical builds on the same machine, just at different enuogh times.
These things boil down to differences in the state of the build machine, as Neil Butterworth pointed out.
来源：https://stackoverflow.com/questions/1277877/gcc-compiled-binaries-w-different-sizes