why do we need the shared library during compile time

Question

Why we need the presence of the shared library during the compile time of my executable? My reasoning is that since shared library is not included into my executable and is loaded during the runtime, it is not supposed to be needed during compile time. Or Am I missing something?

#include<stdio.h>
int addNumbers(int, int); //prototype should be enough, no? 
int main(int argc, char* argv[]){
  int sum = addNumbers(1,2);
  printf("sum is %d\n", sum);
  return 0;
}

I had the libfoo.so in my current dir but I changed its name to libfar.so to find that shared lib is needed at compile or it doesn't compile.

gcc -o main main.c -L. -lfoo gives main.c:(.text+0x28): undefiend reference to 'addNumber'

I think it should be enough to only have the name of the shared library. The shared library itself is not needed since it is found in the LD_LIBRARY_PATH and loaded dynamically at runtime. Is there something else needed other than the name of the shared lib?

You're also having the compiler perform the linking step. Try `gcc -c -o main.o main.c`. — nemequ, Feb 13 '18 at 16:09
adding `-undefined dynamic_lookup` will tell the compiler to assume any undefined symbols will be resolved when dynamic linking happens — C_Elegans, Feb 13 '18 at 16:12
@Gab是好人 - With GCC, it's a bit involved actually... https://stackoverflow.com/questions/23485489/does-clang-gcc-really-support-a-delay-loading-feature — StoryTeller - Unslander Monica, Feb 13 '18 at 16:12
And come to think of it, I think the question I linked may be a duplicate to yours... — StoryTeller - Unslander Monica, Feb 13 '18 at 16:13
@StoryTeller Is it? The question in link is about delay loading on Linux, not how `gcc` uses `-l` options. — yugr, Feb 13 '18 at 16:23
@yugr - Reading this I gathered the OP wanted to know why it doesn't work as she'd expect for "loading at run-time". You'd notice I didn't vote to close it, given the margin of error in my assessment. Left it to he OP to decide. — StoryTeller - Unslander Monica, Feb 13 '18 at 16:27
If you write code using `dlopen`, `dlsym`, etc, then you don't need the library until you run it. But when you use the linker, it looks up things like symbol versions and the real library name. I.E. you link to `libfoo` but then the linker *really* links you to `libfoo.so.4` — Zan Lynx, Feb 13 '18 at 18:02
@Gab是好人 It is not an option of the binutils linker `ld`. It is supported by `ld` on macOS. See https://www.manpagez.com/man/1/ld/ — Jingguo Yao, Sep 15 '20 at 08:59
Coming from a Windows background, I know that it's possible to link against an _import library_ and not have access to the actual DLL at compile time (of course the DLL is eventually needed at run-time, but only the .lib import library is needed for linking). Furthermore, there's a way to access the functions of the DLL without using an import library at all (LoadLibrary, GetProcAddress) so I find this question very relevant. I would hope that answers will address this aspect of it too. — Wyck, Mar 03 '21 at 15:01

score 16 · Accepted Answer · answered Feb 13 '18 at 16:20

Nothing is needed at compile time, because C has a notion of separate compilation of translation units. But once all the different sources have been compiled, it is time to link everything together. The notion of shared library is not present in the standard but is it now a common thing, so here is how a common linker proceeds:

it looks in all compiled modules for identifiers with external linkage either defined or only declared
it looks in libraries (both static and dynamic) for identifiers already used and not defined. It then links the modules from static libraries, and stores references from dynamic libraries. But at least on Unix-likes, it needs to access the shared library for potential required (declared and not defined) identifiers in order to make sure they are already defined or can be found in other linked libraries be them static or dynamic

This produces the executable file. Then at load time, the dynamic loader knows all the dynamic modules that are required and loads them in memory (if they are not already there) along with the actual executable and builds a (virtual) memory map

So, it is mostly to record the name and version of required shared libraries in the executable. — sanjivgupta, Feb 14 '20 at 20:25

Code-Apprentice · Answer 2 · 2018-10-11T15:30:59.703

-1

gcc -o main main.c -L. -lfoo

This command does (at least) two steps: compile main.c into an object file and link all resources into an executable main. The error you see is from the last step, the linker.

The linker is responsible for generating the final executable machine code. It requires the shared object library because it needs to generate the machine code which loads it and executes any functions used in it.

edited Oct 11 '18 at 15:30

answered Feb 13 '18 at 16:12

Code-Apprentice

81,660
23
145
268

2

Isn't the declaration of the function enough for the linker? At linking time by `ld`, does ld really need the definition of the function in the shared lib? – Gab是好人 Oct 11 '18 at 15:21
@Gab是好人 Yes, in order to link the executable, the linker needs the definition of the function to be available. – Code-Apprentice Oct 11 '18 at 15:30
2

Why? we have the dynamic linking at load time. What is the information in the definition of the functions that is needed by the linker, or what the linker `ld` needs to know in the definition of the function ? – Gab是好人 Oct 11 '18 at 15:47
2

@Gab是好人 The executable needs to know the address of the function within the shared object file in order to generate the correct function call. – Code-Apprentice Oct 11 '18 at 15:56
Really? why the runtime linker can't do that? – sanjivgupta Feb 14 '20 at 20:23
@sanjivgupta I'm not sure what you mean by "run time linker". Linking happens at build time. – Code-Apprentice Feb 14 '20 at 20:24
3

@Code-Apprentice The shared object are loaded and linked against at run-time. The executable stores the name of the shared library and the path of the dynamic-linker inside it. The dynamic linker (usually ld.so) loads the shared library and finds the address of the symbol. So, IMO, the actual linking with shared objects occur at execution time. But as pointed in the above answer, a verification happens at build time and the names of the shared library is recorded in the executable. – sanjivgupta Feb 20 '20 at 19:17
1

@sanjivgupta. Wanted to add, in addition to recording shared library names, additional relocation information of shared symbols, like default values present in other libraries are also added, which needs to be initialized as soon as the dynamic object file is loaded. more info - https://eli.thegreenplace.net/2011/08/25/load-time-relocation-of-shared-libraries/#:~:text=Extra%20credit%20%232%3A%20Referencing%20shared%20library%20data%20from%20the%20executable – Akash Feb 10 '23 at 10:46

why do we need the shared library during compile time

2 Answers2

Linked