From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris McGee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <4F34B441-B3E8-41AF-A0C0-14F3F39B84E4@yahoo.ca> Date: Sat, 3 Sep 2016 12:58:46 -0400 References: In-Reply-To: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Linker and duplicate symbols Topicbox-Message-UUID: 9cceb87c-ead9-11e9-9d60-3106f5b1d025 Thanks Steve, I will give these strategies a try. Chris > On Sep 2, 2016, at 6:34 PM, Steve Simon wrote: >=20 > the linker rejects later instances of symbols if it had already found an i= nstance. the important point however is that this is done on a per file basi= s if the symbol is in a library. >=20 > 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 s= econd instance of clock on the command line. >=20 > this means both copies of clock are forced into the linkage, one directly t= hrough a call to clock, the other through the other reference. >=20 > what I have done to find these in the past (crude but effective) is to del= ete both files which contain the clock call (for libc use "ar d") then run m= k again and see what complains. >=20 > my bet is there will be unresolved calls to clock, and something else that= shouldn't be there... >=20 > good luck, >=20 > -Steve >=20 >> 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 >=20