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@xxxxxxxxx> 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. >
