If the shared library for printf is missing on my linux machine,
I'm expecting an error at the time of loading instead of happening
it while linking. Is this a correct assumption?
If thats the case, how we are getting linker error for a typo error
for printf and loader error for missed library? My assumption
is because the prototype for printf can be visible while linking
and with a hope of resolving it while loading they are continuing with
linking.
Please correct my understanding if it's wrong.
Thanks,
Deepak
> If the shared library for printf is missing on my linux machine,
> I'm expecting an error at the time of loading instead of happening
> it while linking. Is this a correct assumption?
It depends what you mean by "while linking". With shared libraries,
linking takes place both right after compiling and right after
loading. The first linking takes place to produce the executable, the
second to attach the shared libraries to it at run time.
> If thats the case, how we are getting linker error for a typo error
> for printf and loader error for missed library? My assumption
> is because the prototype for printf can be visible while linking
> and with a hope of resolving it while loading they are continuing with
> linking.
You need more than a prototype to attach to a symbol in a shared
library. Among other things, you have to know which shared library to
look in.
> Please correct my understanding if it's wrong.
Dynamic linking, at compile and executable production time, works just
like static linking. Except instead of statically linking to the
underlying function, you statically link to a stub. At run time, the
stub is hooked into the shared library. If you misspell printf, you
will fail at local link time because there is no stub to statically
link to. If the library is missing, you will fail at run time because
the stub will not have anything to dynamically link to.
DS
There is also LD_BIND_NOW that controls the deferred symbol resolution
during execution.