The math functions in math.h have implementations in libm.so (or libm.a
for static linking), and libm is not linked in by default. There are
historical reasons for this libm/libc split, none of them very convincing.

The functions in stdlib.h and stdio.h have implementations in libc.so
(or libc.a for static linking), which is linked into your executable by
default (as if -lc were specified). GCC can be instructed to avoid this
automatic link with the -nostdlib or -nodefaultlibs options.

Remember that C is an old language and that FPUs (Floating-Point Units)
are a relatively recent phenomenon. I first saw C on 8-bit processors
where it was a lot of work to do even 32-bit integer arithmetic. Many of
these implementations didn't even have a floating point math library
available!

Even on the first 68000 machines (Mac, Atari ST, Amiga), floating point
coprocessors were often expensive add-ons.

To do all that floating point math, you needed a pretty sizable
library. And the math was going to be slow. So you rarely used
floats. You tried to do everything with integers or scaled
integers. When you had to include math.h, you gritted your teeth. Often,
you'd write your own approximations and lookup tables to avoid it.

Trade-offs existed for a long time. Sometimes there were competing math
packages called "fastmath" or such. What's the best solution for math?
Really accurate but slow stuff? Inaccurate but fast? Big tables for trig
functions? It wasn't until coprocessors were guaranteed to be in the
computer that most implementations became obvious. I imagine that
there's some programmer out there somewhere right now, working on an
embedded chip, trying to decide whether to bring in the math library to
handle some math problem.

That's why math wasn't standard. Many or maybe most programs didn't use
a single float. If FPUs had always been around and floats and doubles
were always cheap to operate on, no doubt there would have been a
"stdmath".

