Functions are not loaded?!!

[ali hagigat]

Thank you very much.

Linker is not a loader!! necessarily. Considering Linux, Loader is
part of kernel which tries to bring the executable made by linker into
RAM and assign a virtual/physical space for it.
Using the word, "load" is not correct in my opinion here. Linker is
making a file, an executable file.
Instead of writing "those functions may not be loaded."  , it can say
that those functions may not be written in the final image made by
linker.
Now I have a new question, so when we want to use a library we must
put it in the rightmost place of a command line to make sure that all
the necessary functions are written in the final image by the linker,
is that right?

On Sun, May 1, 2011 at 12:03 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 30 April 2011 12:56, ali hagigat wrote:
>> 3.13 Options for Linking
>> -llibrary
>> -l library
>> Thus, ‘foo.o -lz bar.o’ searches library ‘z’ after file ‘foo.o’ but before
>> ‘bar.o’. If ‘bar.o’ refers to functions in ‘z’, those functions may
>> not be loaded.
>> -------------------------------
>> What does it mean "those functions may not be loaded"?
>
> (Do you understand what a linker does?  If not, you should read up on
> that instead of trying to read the gcc manual and asking questions
> about every option.)
>
> It means that if libz contains the definition of a function 'xyz' and
> bar.o contains a call to 'xyz' then the symbol may not be resolved,
> because the linker searches libz before it sees the unresolved symbols
> in bar.o.  When the linker processes libz it hasn't seen bar.o so it
> doesn't know to load the 'xyz' function. When it processes bar.o it
> sees the reference to 'xyz' but it won't load it from libz, because it
> has already finished processing libz.
>
>> Where they will be loaded?
>
> In to the resulting executable, from the library that defines them.
>