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.

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

  • 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 9 '17 at 9: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 9 '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 9 '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 9 '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 9 '17 at 11:52

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

  • 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 9 '17 at 6: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 9 '17 at 6:30

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.