From mboxrd@z Thu Jan 1 00:00:00 1970 References: From: Steve Simon Content-Type: text/plain; charset=us-ascii In-Reply-To: Message-Id: Date: Fri, 2 Sep 2016 23:34:18 +0100 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: [9fans] Linker and duplicate symbols Topicbox-Message-UUID: 9c989c56-ead9-11e9-9d60-3106f5b1d025 the linker rejects later instances of symbols if it had already found an ins= tance. the important point however is that this is done on a per file basis i= f the symbol is in a library. the case where I have seen this is your code (the kernel code in this case) r= eferences another symbol which only exists in the file that contains the sec= ond instance of clock on the command line. this means both copies of clock are forced into the linkage, one directly th= rough 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 delet= e both files which contain the clock call (for libc use "ar d") then run mk a= gain and see what complains. my bet is there will be unresolved calls to clock, and something else that s= houldn't be there... good luck, -Steve > On 2 Sep 2016, at 21:00, Chris McGee wrote: >=20 > Thanks Cinap, Richard, >=20 > That makes sense and was probably obvious or in a man page somewhere. >=20 > Chris >=20 >> On Sep 2, 2016, at 12:12 PM, cinap_lenrek@felloff.net wrote: >>=20 >> 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). >>=20 >> the kernel does link in some standard libc functions, but obviously >> not the ones attempting syscalls :) >>=20 >> -- >> cinap >>=20