Thanks Steve, I will give these strategies a try.
Chris > On Sep 2, 2016, at 6:34 PM, Steve Simon <st...@quintile.net> wrote: > > 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 <sirnewton...@yahoo.ca> 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, cinap_len...@felloff.net 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 > >
