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. In particular, you can build GCC on Linux systems with [musl-libc][3] or with [Bionic][4] (Android systems) or with with [dietlibc][5], etc.

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][6].

> 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][7] 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`][8]

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

<sup>(hence the GCC developers and the GNU libc developers do have to interact)</sup>

 [1]: http://gcc.gnu.org/
 [2]: https://en.wikipedia.org/wiki/C_standard_library
 [3]: http://musl-libc.org/
 [4]: https://en.wikipedia.org/wiki/Bionic_%28software%29
 [5]: https://www.fefe.de/dietlibc/
 [6]: https://en.wikipedia.org/wiki/Cross_compiler
 [7]: https://en.wikipedia.org/wiki/Crt0
 [8]: https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html
 [9]: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
 [10]: https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html