the linker rejects later instances of symbols if it had already found an instance. the important point however is that this is done on a per file basis if the symbol is in a library.
the case where I have seen this is your code (the kernel code in this case) references another symbol which only exists in the file that contains the second instance of clock on the command line. this means both copies of clock are forced into the linkage, one directly through a call to clock, the other through the other reference. what I have done to find these in the past (crude but effective) is to delete both files which contain the clock call (for libc use "ar d") then run mk again and see what complains. my bet is there will be unresolved calls to clock, and something else that shouldn't be there... good luck, -Steve > On 2 Sep 2016, at 21:00, Chris McGee <[email protected]> wrote: > > Thanks Cinap, Richard, > > That makes sense and was probably obvious or in a man page somewhere. > > Chris > >> On Sep 2, 2016, at 12:12 PM, [email protected] wrote: >> >> uses the first one it finds, so the order matters. its not unusual >> for programs to override certain library function by providing ther >> own version and putting them first in the object file list. this >> works only when the function you want to replace sits alone in his >> own object file (the smallest unit of linkage). >> >> the kernel does link in some standard libc functions, but obviously >> not the ones attempting syscalls :) >> >> -- >> cinap >>
