19

GCC is the C compiler. Glibc is the C library. However, isn't it an absolute necessity for a compiler and the standard library bundled together as a C implementation?

For example, the C library contains ABI and compiler specific stuff like <limits.h>, <stdint.h>, etc., which differs between compilers and APIs. 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. For example, if I change the compiler to work with another ABI, like using int with 8 bytes, the C library will no longer works because the stuff in <limits.h> will become wrong.

Michael Tsang
  • 810
  • 2
  • 7
  • 13

2 Answers2

27

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 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, 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), bypassing appropriate extra arguments to gcc ...

Chen Li
  • 123
  • 4
Basile Starynkevitch
  • 32,434
  • 6
  • 84
  • 125
  • 1
    Correct answer, even if not a correct design. This is why MSVC++ can compile C++11/C++14 code for pre-2011/2014 Operating Systems, but GCC usually cannot. – MSalters May 09 '17 at 09:07
  • What do you mean by "not a correct design"? And I am not sure that GCC cannot compile C++14 code for old OSes (however, you might need to compile a recent GCC on that older OS). – Basile Starynkevitch May 09 '17 at 10:08
  • According to ISO C, the C Standard Library is part of the compiler. The same holds for the C++ library. Now the problem is that applications built with a new GCC version will have a dependency on the glibc of the OS where they're built, which may be newer than the glibc on the target system. A better solution probably would have relied on a `gcclibc` which builds upon OS libraries, but is versioned as part of GCC and not the OS. – MSalters May 09 '17 at 11:30
  • Are you sure that the C11 or C++14 standards mention the word "compiler"? AFAIU they speak of "implementation" (which might not even be a software) – Basile Starynkevitch May 09 '17 at 11:36
  • I'd have to double-check, but I think they don't (interpretation is still a legal strategy AFAIK). And technically speaking the Standard doesn't care exactly how the Standard Library is implemented; a forward to the OS library is OK. But _every_ C11 respectively C++11 function has to be available. GCC doesn't support C11 on older OS'es when it relies on the OS to provide certain C11 functions. To a degree, that can be reasonable (threads on older OS'es!) but even fairly recent Linux distributions aren't supported. – MSalters May 09 '17 at 11:52
  • After I compiled a C program containing an empty main function, there is a reference to `__libc_start_main` in glibc, which suggests that the `main` function is called by glibc. And for the point to another ABI, if I rebuilt by compiler to use a different ABI, then the C library will not work even when I recompile it? For example, If I want to use two programs, one with 4 byte int, another with 8 byte int on the same machine, I have to change the C library source before recompiling it with another ABI? – Michael Tsang May 12 '17 at 07:10
  • I have another problem then: why the C library is distributed with the OS, but not treated as "yet another library" on UN*X systems? I expect that C libraries are distributed with the compilers, just like distributing `libstdc++` with G++, and programs compiled with a specific compiler link with the C library with that specific compiler (i.e. I would expect that a program using GNU extensions of `printf` work everywhere when built with GCC) – Michael Tsang May 12 '17 at 07:20
  • Your expectation is wrong. Standard C libraries are *not* distributed with GCC – Basile Starynkevitch May 12 '17 at 07:29
  • but if the C library is not distributed with the compiler, how do the library know the implementation detail of the compiler, like the size of int in ``, the calling convention, etc., of the compiler? – Michael Tsang May 13 '17 at 14:19
  • 1
    Some headers, like `` or `` are indeed provided by GCC. Other headers, like `` a taken from the C library and "fixed" during GCC build. – Basile Starynkevitch May 13 '17 at 15:19
  • 1. If I compile GCC natively on a machine with a 3rd party C compiler and 3rd party C library, and then compile application including both `` and ``, where will the libraries come from? 2. If, after doing 1, I compile a copy of glibc with the gcc, then install it alongside with the 3rd party C library, will I be able to choose which C library to use using either the 3rd party compiler or GCC? – Michael Tsang May 16 '17 at 02:57
-5

The short answer is that if the two were 'bundled' together, glibc would be licensed under the GPL*, and it would therefore be completely unsuitable for proprietary projects. While the FSF and GNU project has no love for proprietary software, glibc was licensed LGPL as a strategic choice to advance adoption of GCC and the free software ecosystem. GCC is actually licensed under the GPL with a specific runtime linking exception, because the situation is somewhat muddy. glibc is licensed per the LGPL to permit sensible shared-library situations.

https://www.gnu.org/licenses/gcc-exception-faq.html

Additionally, glibc has all kinds of shims and other components to adapt it for varying operating systems, and distributing that as the same package as gcc would also make things messy.

*Alternativly, GCC could be licensed under something other GPL, though the FSF's thoughts on that would be along the lines of "over my dead body".

whatsisname
  • 27,463
  • 14
  • 73
  • 93
  • 3
    Sorry, but this answer is IMHO wrong. "Bundling together" does not imply glibc beeing a "derived work" from GCC in the sense described in the GPL. For example, tons of software packages using different open source licenses are "bundled together" in each Linux distro, nevertheless these packages don't violate the GPL. – Doc Brown May 09 '17 at 06:30
  • Why would bundling gcc and glibc together force glibc to be under the GPL? My understanding was that bundles are not a "combined work", so the GPL doesn't cross the boundary. Edit: what Doc Brown said :-) – Philip Kendall May 09 '17 at 06:30