See, right here is where you prove that you really don't know what the hell you are talking about. Two points.

One:

Who says you need to use ANY libraries?

It is entirely possible to write a fully-functional microcontroller application, one that meets the design specifications, without using the standard, or any other, libraries. In fact, I am revisiting the C source code for a test fixture I built a couple of years because I'm reusing it for a different fixture. It does not use any standard (or other) libraries. It's about 3203 bytes, according to the Keil report.

Now I just looked at a different 8051 project. I do use string.h and the standard library because I make a lot of use of strcpy() and strcmp(), and I use stdio.h because I use atol() and sprintf(). The program does a whole bunch of command parsing (read from serial port, parse command, do something), and even with the use of sprintf(), the compiled code is still 3460 bytes.

Sure, I could have written my own string compare and copy and all of that, but why? Keil did the work for me, and their library is as compact as can be. Why reinvent the wheel?

Two:

You obviously don't understand the point of header files.

The most obvious use of header files is to expose a function's declaration to other source files. All sources are compiled individually, which means that source foo.c has no idea that source bar.c even exists. So consider that the code in foo.c wants to call a function in bar.c. When the compiler sees a call to doBar() in foo.c, it'll complain: "function not defined" or similar.

So for functions in bar.c that are called by other sources, you create a header file bar.h which contain just the function declaration:

void doBar(int arg1, char *argc);

and you #include "bar.h" in foo.c and now the compiler can continue working on foo.c because it knows that somewhere a function called doBar() with the specified signature exists.

Depending on your project, your source list can include bar.c, and the compiler will compile that in due time. Note that the order of compilation is irrelevant: headers with function definitions ensure that each source has everything it needs to compile. Alternatively, you could have a (GASP!) library where you've precompiled bar.c, and perhaps some other stuff, so you don't have to keep recompiling those sources.

It is the job of the linker to put it all together. It builds the executable from the various compiled objects and libraries. A good linker will pull in from libraries only functions that are called. If a library has a dozen functions and you only use one, your executable will not have any binary code for the uncalled 11 functions.

Hopefully this little tutorial will help you understand why you are completely wrong about C.

-a