Disclaimer: I am fairly new to Ubuntu. I have a reasonable amount of experience with RHEL and SLES, and have had to learn Ubuntu LTS versions recently because of some ARM64 hardware that doesn't want to boot anything else.

Summary

Ubuntu releases do, indeed, often come with some components from a later GCC than the releases' default GCC. They apparently do this so that they can provide later compiler versions, if you want to use them.

• The gcc-10-base package just provides documentation.
• The libgcc-s1 package provides an important library, libgcc_s.so.1. That provides helper functions for code generated by the compiler: I know it as important for handling C++ exceptions being thrown through a C call stack.
• Another important library is libstdc++.so.6. That provides C++ support functions.
• Glibc (libc.so.6, libm.so.6 and other libraries) is also important, but is not tied to a GCC version.

All of these libraries have very strong compatibility rules. Essentially, a later version of the library will always be compatible with earlier versions, discounting some ancient versions from the early history of GCC and Linux.

It isn’t obvious at first why Ubuntu and Debian provide run-times that are later than the compiler, but it gets clearer when you look at the range of GCC versions available on recent Ubuntu LTS versions:

Distribution Released Debian GCC run-times Default GCC Additional GCCs
Ubuntu 16.04 Apr 2016 9.x 5.x 5.4 4.7, 4.8, 4.9
Ubuntu 18.04 Apr 2018 10.x 8.x 7.5 4.8, 5.5, 6.5. 8.4
Ubuntu 20.04 Apr 2020 11.x 9.x & 10.x 9.3 7.4, 8.4, 10.3
Ubuntu 22.04 Apr 2022 12.x 12.x 11.4 9.5, 10.5, 12.3

At that that point, it becomes reasonably obvious. Ubuntu 20.04 has the run-times for code compiled with GCC 9.x and 10.x (GCC 10.x doesn't demand any additional library functions that GCC 9.x didn't use). You can install any mixture of GCC 7.4, 8.4 and 10.3 as extra compilers, and they'll all work. The run-time libraries on Ubuntu 20.04 will support code compiled with any of those compilers.

Why not ship GCC 10.3 with Ubuntu 20.04? Run-time libraries are generally more stable than compilers. GCC 10 would have been first released (as 10.1) about the time that 20.04 was being put together. Building an LTS release with a brand-new compiler would be foolhardy; shipping new run-time libraries, after testing them with code built with GCC 9, is a lot safer and allows GCC 10 to be added when it has stabilised.

Canonical don't provide GCC 11 for 20.04 because it doesn't have the necessary run-times. For those, you need a later Ubuntu.

How to find all this stuff out

/usr/share/doc/gcc/README.Debian has some information.

dpkg-query --listfiles gcc-10-base shows us that gcc-10-base only provides documentation.

dpkg-query --listfiles libgcc-s1 shows us that libgcc-s1 provides /lib/x86_64-linux-gnu/libgcc_s.so.1, which is one of the basic run-time libraries for GCC.

The other basic run-time libraries for C/C++ are glibc, which is independent of GCC, and libstdc++. dpkg-query -list | grep libstdc shows us two packages:

ii libstdc++-9-dev:amd64 9.3.0-17ubuntu1~20.04 amd64 GNU Standard C++ Library v3 ...
ii libstdc++6:amd64 10.3.0-1ubuntu1~20.04 amd64 GNU Standard C++ Library v3

libstdc++6 is the GCC 10.3 version; the -dev package is the GCC 9.3 version.

dpkg-query --listfiles libstdc++-9-dev shows us that this package provides header files, archive libraries and documentation for developing in C++ with GCC 9.

dpkg-query --listfiles libstdc++6 shows us that this package provides documentation, some Python scripts and two really important files:

/usr/lib/x86_64-linux-gnu/libstdc++.so.6
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28

The .so.6 file is what programs are linked against. It is actually a softlink to the .so.6.028 file. That’s the name of the GCC 10 version of libstdc++, the GCC support library for C++. You can get the mapping between those names and GCC versions here. Scroll down, and you’ll find some tables.

GCC used for building Ubuntu

The easiest thing to check is glibc. Building this with a different compiler from the rest of the OS would be crazy, and you can find out what compiler was used to build it just by asking:

/usr/lib/x86_64-linux-gnu/libc.so.6
GNU C Library (Ubuntu GLIBC 2.31-0ubuntu9.7) stable release version 2.31.
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 9.3.0.
libc ABIs: UNIQUE IFUNC ABSOLUTE
For bug reporting instructions, please see:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bugs.

Yes, you do need it .... probably. If you don't need it then statically linking it is harmless. You can tell if you need it by using the -t link trace option (I think).

There are various things that you cant do in one instruction (typically things like 64-bit operations on 32-bit architectures). These things can be done, but if they use a non-trivial number of instructions then it's more space-efficient to have them all in one place.

When you disable optimization using -O0 (that's actually the default anyway) then GCC pretty much always uses the libgcc routines.

When you enable speed optimization then GCC may choose to insert the instruction sequence directly into the code (if it knows how). You may find that it ends up using none of the libgcc versions - it will certainly use fewer libgcc calls.

When you enable size optimizations then GCC may prefer the function call, or may not - it depends on what the GCC developers think is the best speed/size trade-off in each case. Note that even when you tell it to optimize for speed, the compiler may judge that some functions are unlikely to be used, and optimize those for size - even more so if you use PGO.

Basically, you can think of it in the same way as memcpy or the math-library functions: the compiler will inline functions it judges to be beneficial, and call library functions otherwise. The compiler can "inline" standard functions and libgcc function without looking at the library definition, of course - it just "knows" what they do.

Whether to use static or dynamic libgcc is an interesting trade-off. On the one hand, a dynamic (shared) library will use less memory across your whole system, and is more likely to be cached, etc. On the other hand, a static libgcc has a lower call overhead.

The most important thing though is compatibility. Obviously the libgcc library has to be present for your program to run, but it also has to be a compatible version. You're ok on a Linux distro with a stable GCC version, but otherwise static linking is safer.

I hope that answers your questions.

libgcc_s.so is a shared library, libgcc.a is a static library. They are not equivalent; it may be necessary to link both. libgcc_s contains global variables which must not have multiple copies in a process; the code in libgcc is safe to link multiple times.

Libgcc is even more fundamental than libc. Libgcc contains code that is used by the GCC compiler when generating code for fundamental language constructs, such as 64-bit arithmetic on 32-bit platforms, stack maintenance, integers and floating point operations that the hardware doesn't perform, etc.

Debian's gcc-base package contains only a couple of symbolic links and a few documentation files for libgcc.

You can't remove these packages, even if you never compile anything, because they aren't here to compile stuff. They are not for running GCC, they are for running software compiled with 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 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 ...