One of the reasons is that [GCC][1] can be built and used on (e.g. proprietary Unix systems like MacOSX, Solaris, HPUX or some FreeBSD) systems having their own [C standard library][2]. Even on Linux, you can have a C standard library which is not the [GNU Glibc][3]. In particular, you can build GCC (or use it) on Linux systems with [musl-libc][4] or with [Bionic][5] (Android systems) or with with [dietlibc][6], etc. And a Linux system could have the GNU Glibc and use some other C compiler (like [Clang][7] or TinyCC). Also, the C library heavily depends upon the Linux kernel. Some old versions of the kernel might require some particular kind (or version) of `libc` And GCC is buildable as a [cross-compiler][8]. > And details like "how to call a `main` function" also depends on the compiler, but in fact those details are supplied by `libc.so` on a Linux system. That is not exactly correct. The `main` function is called (in a hosted environment) by the [crt0][9] stuff, some of which is provided by GCC (e.g. `/usr/lib/gcc/x86_64-linux-gnu/6/crtbegin.o` on my Debian/Sid/x86-64 is from the `libgcc-6-dev` package). Read also about [`libgcc`][10] Actually, there is some half-hidden relation between `libc` and GCC, e.g. because many `libc` headers are (optionally) using some gcc [builtins][11] or [function attributes][12]. <sup>(hence the GCC developers and the GNU libc developers do have to interact)</sup> > .... if I change the compiler to work with another ABI .... You'll need to ...`/configure` the GCC compiler and rebuild it, and you might even need to *patch* the GCC compiler (to describe your ABI and [calling conventions][13]). The [x32 ABI][14] is a good example. At last, some contributors to or maintainers of GCC (including me) have signed a [copyright assignment][15] which covers GCC but not the GNU glibc. <sup>(regarding GCC license, read carefully [GCC runtime library exception][16])</sup> Notice that some standard headers, like `<limits.h>` or `<stdint.h>` are provided by GCC; others, like `<stdlib.h>` are "fixed" during GCC build: the compiler build procedure takes them from the Libc implementation and patches them. Still other standard headers (probably `<stdio.h>` and the internal headers it is including) are taken from the libc. Read more about [GCC FIXINCLUDES][17] and [Fixed Header Files][18]. <sup>(the fixincludes thing is something I (Basile) still don't understand well)</sup> You could compile with `gcc -v -H` to understand more precisely which actual programs are run (since `gcc` is a driver, running the `cc1` compiler, the `ld` & [`collect2`][19] linkers, the `as` assembler, etc...) and which headers are included. Read more about GCC [options][20]. [1]: http://gcc.gnu.org/ [2]: https://en.wikipedia.org/wiki/C_standard_library [3]: https://www.gnu.org/software/libc/ [4]: http://musl-libc.org/ [5]: https://en.wikipedia.org/wiki/Bionic_%28software%29 [6]: https://www.fefe.de/dietlibc/ [7]: http://clang.llvm.org/ [8]: https://en.wikipedia.org/wiki/Cross_compiler [9]: https://en.wikipedia.org/wiki/Crt0 [10]: https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html [11]: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html [12]: https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html [13]: https://en.wikipedia.org/wiki/Calling_convention [14]: https://en.wikipedia.org/wiki/X32_ABI [15]: https://gcc.gnu.org/contribute.html#legal [16]: https://www.gnu.org/licenses/gcc-exception [17]: https://www.gnu.org/software/autogen/fixinc.html [18]: https://gcc.gnu.org/onlinedocs/gcc/Fixed-Headers.html [19]: https://gcc.gnu.org/onlinedocs/gccint/Collect2.html [20]: https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html