3

I think I've read that compiling multiple files with gcc at the same time would achieve the same thing as adding all sources into a single source file, as per Single Compilation Unit, but I can't find any sources on that anymore. Is that true?

We are currently trying to shrink a binary to the smallest size possible and are applying multiple techniques to achieve that. We reached the point where the discussion is about the differences between Single Compilation Unit, Link Time Optimization and changing the build to compile all sources in a single compiler call, something like gcc -o binary $CFLAGS $INCLUDES $CDEFS a.c b.c c.c d.c e.c.

klutt
  • 30,332
  • 17
  • 55
  • 95
Spidey
  • 2,508
  • 2
  • 28
  • 38
  • 7
    To the question in the title: No. – Eugene Sh. Feb 26 '19 at 18:34
  • Dirty hack: create a separate source file that `#include`'s the other source files and compile that. – dbush Feb 26 '19 at 18:36
  • @dbush Not going to work if these have for example, `static` variables with same name. – Eugene Sh. Feb 26 '19 at 18:37
  • @dbush oh-oh. Better amalgamate it through the script. `include` on .c file is just an abomination. And Eugene is correct too. – SergeyA Feb 26 '19 at 18:37
  • many linkers now support linked time optimization (lto). – OznOg Feb 26 '19 at 18:39
  • @SergeyA You are familiar with the term "Dirty hack"? ;) – Ctx Feb 26 '19 at 18:40
  • Have you tried compiling with the `-s` option to strip the symbols from the executable? It should reduce the binary's size and make it super fun to debug any run time issues. – bruceg Feb 26 '19 at 18:50
  • LTO is probably the closest you will get to a compiler being able to optimize multiple translation units as if the code were refactored to coexist in a single translation unit. – jxh Feb 26 '19 at 18:51
  • @Sergey that is called a unity build and is not an abonimation, it’s something great. – Fredrik Feb 26 '19 at 19:01
  • @Fredrik "One man's meat is another man's poison". Suit yourself. – SergeyA Feb 26 '19 at 19:03
  • As far as I know, the C standard does not say anything about this so it's upp to the compiler. – klutt Feb 26 '19 at 19:09

1 Answers1

4

No. Each independent .c file passed to a compiler is considered a single translation unit, so multiple files passed to a compiler produce multiple independent translation units.

SergeyA
  • 61,605
  • 5
  • 78
  • 137
  • 1
    For OP's reference, you can easily verify this by just running the suggested command under `strace -f`. You'll see the compiler invoked for each source file, and then the assembler invoked for the same number of temporary .s files, followed by the linker. – Useless Feb 26 '19 at 18:43
  • 1
    Or just run it with `-c` and observe the bunch of object files generated. – Eugene Sh. Feb 26 '19 at 18:46
  • Using `gcc -v` (verbose) also shows what commands are executed, and therefore each source file being processed separately. – Jonathan Leffler Feb 26 '19 at 19:25
  • What are independent .c files? If code in one of the .c files depends on code in another, are they treated as one translation unit? – Eric Postpischil Feb 26 '19 at 19:34
  • @EricPostpischil independent here means 'separate' or 'individual'. Each .c file is a single translation unit, period. – SergeyA Feb 26 '19 at 20:17
  • @SergeyA: Do you think students will all know that? Or should it be in your answer? Also, if `a.c` includes separate file `b.c`, are they different units because they are separate and individual files or one unit because one depends on the other? How should a student know how to answer this? – Eric Postpischil Feb 26 '19 at 20:30