c - Why does the order of '-l' option in gcc matter? -

i trying compile program uses udis86 library. using example program given in user-manual of library. while compiling, gives error. errors are:

example.c:(.text+0x7): undefined reference 'ud_init' example.c:(.text+0x7): undefined reference 'ud_set_input_file' . . example.c:(.text+0x7): undefined reference 'ud_insn_asm' 

the command using is:

$ gcc -ludis86 example.c -o example  

as instructed in user-manual.

clearly, linker not able link libudis library. if change command to:

$ gcc example.c -ludis86 -o example  

it starts working. can please explain problem first command?

because that's how linking algorithm used gnu linker works (a least when comes linking static libraries).

a library collection (an archive) of object files. when add library using -l option, linker not unconditionally take all object files library. takes object files currently needed, i.e. files resolve unresolved (pending) symbols. after that, linker forgets library.

the list of pending symbols continuously maintained linker linker processes input object files, 1 after left right. processes each object file, symbols resolved , removed list, other newly discovered unresolved symbols added list.

so, if included library using -l, linker uses library resolve many pending symbols can, , forgets library. if later discovers needs additional object file(s) library, linker not "return" library retrieve additional object files. late.

for reason, idea use -l option late in linker's command line, time linker gets -l can reliably determine object files needs , doesn't need. placing -l option first parameter linker makes no sense @ all: @ beginning list of pending symbols empty (or, more precisely, consists of single symbol main), meaning linker not take library @ all.

in case, object file example.o contains references symbols ud_init, ud_set_input_file etc. linker should receive object file first. add these symbols list of pending symbols. after can use -l option add library: -ludis86. linker search library , take resolves pending symbols.

if place -ludis86 option first in command line, linker ignore library, since @ beginning not know need ud_init, ud_set_input_file etc. later, when processing example.o discover these symbols , add them pending symbol list. these symbols remain unresolved end, since -ludis86 processed (and ignored).

sometimes, when 2 (or more) libraries refer each other in circular fashion, 1 might need use -l option twice same library, give linker 2 chances retrieve necessary object files library.