What searches have you tried?
Keep in mind the binary runtime process is completely different on Windows comapred with Linux and Mac OS (which, themselves are different but also very similar). Linking, in particular, works differently at the lower levels at both build and run time, so the which files are necessary is going to be different.
A summary of how it all works on any platform, in a vague and general way is as follows.
(1) The compiler translates a single text source file (header files and source files are combined by a preprocessor into a single translation unit) into an intermediate binary "object file" with an extension .OBJ on Windows and traditionally the last two character of the file name are .o on Unix-derived systems. These object files contain a table of unresolved external references.
(2) The linker will take one or more object files and combine them into a dynamic shared object (DSO) such as a shared library or executable program. At this time, all object files plus additional shared libraries need to be available to the linker so it can resolve those unresolved external references.
On all platforms, the only real difference between a "shared object" (.so file, .DLL file) and an executable (on WIndows, a file with a .EXE extension, on other platforms a file with appropriate magic in the first 4 bytes and the executable bit set in the filesystem) is a couple of flags in the binary header and the entry point published (again in the header).
On all systems the linker reads the object files and copies their contents into the DSO, building a table of unresolved references as it goes and resolving references where it can. On Linux (ELF) and Mac OS (MACH-O) systems, the linker reads the .so files to resolve many of the still-unresolved references, recording the SONAME (a special label identifying the DSO) of the .so as it does so. Windows (COFF) systems do something similar, except it usually uses a .LIB files, a specially-build object file, to embed trampoline functions into the executable instead of using a jump table.
A program launch time, another program called the link loader (on ELF systems, it's called 'the interpreter', on Windows it's actually built into the OS) reads the external reference table of the DSO and opens and loads the appropriate .so/.DLL files, updating the jump tables as required.
Really, all the linker does is create a special table of information so that multiple files can be used together at runtime as one single self-contained executable image in memory while being built at different times in different places from multiple source files.
