C unit test common practice

Question

For example, my production code(say it builds to an executable) has

file_a.c (sub_module A)
   int func_a() {
      ....
   }

file_b.c (module B)
   func_b () {
       ...
       ret = func_a();
       ...
   }

For unit test, I am using CppUTest. If I test B with the real code of A, then

1. I need real implementation of A,
2. we might not be able to produces all different possible outputs from func_a().
3. if func_a() calls other module's functions, it is hard to discover/setup all cases deep inside the function call chains.
4. mabybe this is too extreme, but I can't convince ppl how this approach different from linking all code together and simply testing from main()?

But If I mock func_a() while testing B, then linker will complain multiple definitions once I start testing A since now real implementation will be linked. For this issue, I see two ways around it

1. create a separate test executable for each file_a.c and file_b.c. But this will produce so many executables as the production grows, and also complications will happen if some "real" and "mock" combination tests is needed.
2. compile production code as a shared library and link it to the test executable, then use link time interposing to intercept function calls towards the real implementation.

So what is the common practice for such scenarios? I am sure this is a very common scenario for unit testing c code.

Thanks,