9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Steve Simon <steve@quintile.net>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Linker and duplicate symbols
Date: Fri,  2 Sep 2016 23:34:18 +0100	[thread overview]
Message-ID: <B3C68A5B-8628-435B-98B3-546978A728C3@quintile.net> (raw)
In-Reply-To: <BB1501DA-A97E-4111-9C5A-EC0D0336ACF4@yahoo.ca>

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_01@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_lenrek@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
>> 




  reply	other threads:[~2016-09-02 22:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-02  2:34 Chris McGee
2016-09-02 10:20 ` Richard Miller
2016-09-02 15:56   ` Chris McGee
2016-09-02 16:11     ` Richard Miller
2016-09-09  0:48       ` Chris McGee
2016-09-09  8:31         ` Richard Miller
2016-09-09 14:55           ` Chris McGee
2016-09-09 16:37             ` Richard Miller
2016-09-02 16:12     ` cinap_lenrek
2016-09-02 20:00       ` Chris McGee
2016-09-02 22:34         ` Steve Simon [this message]
2016-09-03 16:58           ` Chris McGee

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=B3C68A5B-8628-435B-98B3-546978A728C3@quintile.net \
    --to=steve@quintile.net \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).