I have these modules
sum_module.h
int sum(int x, int y);
tim_module.h
int tim(int x, int y);
I want to create a module called myModule.lib that allows me to use these function in my main program. The idea is to add myModule.lib to the main project and include myModule.h
My question is : When I create the library (myModule.lib), does it contain a main.c and a main.h ? if yes, is main.h equivalent to myModule.h ? What should I put in the main.c ?
your static library is a set of services, so it comes with a header file containing the protoype of the functions you want to expose to the outside. If you don't put a main symbol here, well, noone will put one for you fortunately.
(note that the filename isn't relevant, it's the symbol name which is relevant: main)
It's technically possible to put a main in it (some building tools create a .a file and link with the runtime to create an executable), but as a library of services, that would conflict with any application trying to link with it, that application also having a main.
So leave out the main function as we know it (the famous int main(int argc, char**argv)) out of your library (you can add a selftest entrypoint if you want). Creating a static library doesn't involve any linking, and creating a dynamic library doesn't require a main, just full symbol resolution and entrypoints.
To answer your question it may be worthwile to understand what the basic meaning of compiling and linking a C program from source is, and how libraries come into play.
Compiling a source file creates an object file which you can imagine as "structured machine code". It is structured in that it contains symbols — named variables and named functions. These symbols are essentially labeled memory addresses containing data or machine instructions (namely functions) which can be read or jumped to from other code.
Tools like nm and objdump can be used to inspect object files and list these symbols.
Producing a runnable, statically linked program consists of the two known steps, compiling (producing object files from source files) and linking ("glueing" object files together and performing some magic to produce one runnable entity).1 The linker "resolves" calls to functions in other object files by computing the numerical addresses in the final program to jump to. If such a function is not found, one logically gets the "undefined symbol" error.
A simple static library now is literally nothing more than a concatenation of object files with an index of the symbols it contains. It's that simple. In other words, instead of linking with ld -o output /lib/crt0.o hello.o sum.o tim.o -lc (using the object files coming from an earlier compilation of sum.c and tim.c) you call the archiver ar to produce a static library my_module.a with these two object files in it: ar rcs my_module.a sum.o tim.o Then in the link phase you use this library in place of the two object files: ld -o output /lib/crt0.o hello.o my_modules.a -lc will resolve calls of sum and tim from hello.o with the symbols in that library.
So will you need a main in your library? No. Why would you? You need a main in that library not any more than you need one in sum.c or tim.c (we assume that you have a main in hello.c). Would it hurt? Possibly; linkers complain about "duplicate symbols" because there's no way for them to tell which one is the intended one. Many linkers offer an option to ignore that error and use the first symbol encountered, but normally that's only a workaround until the build process is clean.
gcc, or by a make file or IDE. I haven't actually called the linker ld "manually" in a while. But the purpose here is to give an understanding of the process because that will enable you to answer your own question.