Return to Revisions

One of the reasons is that GCC 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.

Even on Linux, you can have a C standard library which is not the GNU Glibc. In particular, you can build GCC (or use it) on Linux systems with musl-libc or with Bionic (Android systems) or with with dietlibc, etc. And a Linux system could have the GNU Glibc and use some other C compiler (like Clang 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.

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 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

Actually, there is some half-hidden relation between libc and GCC, e.g. because many libc headers are (optionally) using some gcc builtins or function attributes.

^{(hence the GCC developers and the GNU libc developers do have to interact)}

.... 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). The x32 ABI is a good example.

At last, some contributors to or maintainers of GCC (including me) have signed a copyright assignment which covers GCC but not the GNU glibc.

^{(regarding GCC license, read carefully GCC runtime library exception)}