 <p>It's going to depend on a lot of things, here's how you can find out. GNU Binutils comes with a utility <code>objdump</code> that gives all sorts of details on what's in a binary.</p> <p>On my system (an ARM Chromebook), compiling test.c:</p> <pre><code>#include &lt;stdio.h&gt; int main(void) { printf("Hello, world!\n"); } </code></pre> <p>with <code>gcc test.c -o test</code> and then running <code>objdump -R test</code> gives</p> <pre><code>test: file format elf32-littlearm DYNAMIC RELOCATION RECORDS OFFSET TYPE VALUE 000105e4 R_ARM_GLOB_DAT __gmon_start__ 000105d4 R_ARM_JUMP_SLOT puts 000105d8 R_ARM_JUMP_SLOT __libc_start_main 000105dc R_ARM_JUMP_SLOT __gmon_start__ 000105e0 R_ARM_JUMP_SLOT abort </code></pre> <p>These are the dynamic relocation entries that are in the file, all the stuff that will be linked in from libraries external to the binary. Here it seems that the <code>printf</code> has been entirely optimized out, since it is only giving a constant string, and thus <code>puts</code> is sufficient. If we modify this to</p> <pre><code>printf("Hello world #%d\n", 1); </code></pre> <p>then we get the expected</p> <pre><code>000105e0 R_ARM_JUMP_SLOT printf </code></pre> <p>To get <code>memcpy</code> to be explicitly linked to, we have to prevent <code>gcc</code> from using its own builtin version with <code>-fno-buildin-memcpy</code>.</p>