Clang does not come with a linker, it relies on ld instead. And ld depends on libgcc.a and/or libgcc.so on your system (regardless this is the LLVM linker ld.lld or GNU ld). This is the reason why you have this error message.

So the answer is actually:

(a) the linker requires libgcc to do its own linking work

A lot more details on this are available here at omniprog.info:

If we want to get rid of GCC and use clang as our default compiler on the system, we may have to make some adjustments on some RPM-based systems. Clang does not provide a linker, but relies on the system's linker, typically ld, to link executables. This is the case even on FreeBSD and Mac OS X systems where Clang is the default compiler. We can see this using the -v option to clang++. Now, ld won't work without the following files:

libgcc.a
libgcc_s.so
[...]

In some Makefiles it tries to find the search path for libgcc by executing:

$(CC) -print-libgcc-file-name

This fails if no sysroot is defined, so add sysroot manually. Have a look at the config.mk where it says:

CC := $(CROSS_COMPILE)gcc

Change it to:

ifdef PKG_CONFIG_SYSROOT_DIR
CC  = $(CROSS_COMPILE)gcc --sysroot=$(PKG_CONFIG_SYSROOT_DIR)
else
CC  = $(CROSS_COMPILE)gcc
endif

You might try to compile using the option -static-libgcc.

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.