Thanks Steve,
I will give these strategies a try.
Chris
> On Sep 2, 2016, at 6:34 PM, Steve Simon 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 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
>
>
