Return to Answer

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

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.

.... if I change the compiler to work with another ABI ....

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

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 and Fixed Header Files.

BTW, you can use a C standard library different of the one your GCC expects or was built for (e.g. musl-libc or some dietlibc), by passing appropriate extra arguments to gcc ...

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 dietlibc, etc. And a Linux system could have the GNU Glibc and use some other C compiler (like Clang or TinyCC).

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.

.... if I change the compiler to work with another ABI...

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

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 and Fixed Header Files.

BTW, you can use a C standard library different of the one your GCC expects or was built for (e.g. musl-libc or some dietlibc), bypassing appropriate extra arguments to gcc ...

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 linkers, the as assembler, etc...) and which headers are included. Read more about GCC options.

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 linkers, the as assembler, etc...) and which headers are included, which libraries and object files are linked (even implicitly, including the C standard library and the crt0). Read more about GCC options.

BTW, you can use a C standard library different of the one your GCC expects or was built for (e.g. musl-libc or some dietlibc), by passing appropriate extra arguments to gcc ...

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

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 and Fixed Header Files.

^{(the fixincludes thing is something I (Basile) still don't understand well)}

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

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 and Fixed Header Files.

^{(the fixincludes thing is something I (Basile) still don't understand well)}

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 linkers, the as assembler, etc...) and which headers are included. Read more about GCC options.