C++ – File size difference at cross-compile time

I’m writing a small application in C++ that runs on my host (linux x86) and target machine (ARM).
The problem I’m having is that my binary file size is about 700kb on the host, but about 7mb on the target machine.
I use the same compile switch for both platforms. My first thought was that one of the libraries on the arget machine was statically linked, but I checked both binaries with objdump and both used the same dynamic-link library.
So can anyone tell me how to find out why the size difference is so huge?

While different computer architectures

can theoretically require completely different amounts of executable code for the same program, a factor of 10 is not really expected in modern architectures. ARM and x86 may be different, but they are still designed in the same universe where memory and bandwidth cannot be wasted, which leads CPU designers to keep executable code as compact as possible.

Therefore, I will look at the following possibilities in order of probability:

• Symbol stripping: If one of the two binaries has been stripped from its symbols, it will be much smaller, especially when compiling with debugging information. You may want to try stripping both binaries and see what happens.

• Static linking: I occasionally come across build systems for embedded targets that prefer static linking over using shared libraries. Checking the library dependencies of each binary might detect this.

Additional enable code

• : Larger binaries may enable additional code because, for example, the build system discovered an additional optional library, or because the target platform requires a specific handle.

  However, 10x may be too much, unless the smaller binary lacks a lot of functionality, or the larger binary is statically linked to some optional library.

Different compiler

• configurations: You should review not only the compiler options that you provide, but also the default values that the compiler uses for each target. For example, if the compiler has significantly higher inline or loop unwinding limits in one architecture, the resulting executable may be significantly bloated.