From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: David Rientjes <rientjes@google.com>, linux-arch@vger.kernel.org
Subject: Re: Link breakage on all architectures which implement their own show_mem
Date: Fri, 25 Mar 2011 09:11:18 -0500 [thread overview]
Message-ID: <1301062279.4073.1.camel@mulgrave.site> (raw)
In-Reply-To: <1301050500.2402.487.camel@pasglop>
On Fri, 2011-03-25 at 21:55 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2011-03-23 at 11:41 -0500, James Bottomley wrote:
> > oom: suppress nodes that are not allowed from meminfo on oom kill
> >
> > Is the cause. What it does is introduce a new __show_mem() which is
> > required by files in mm/, so the object containing it: show_mem.o gets
> > pulled in all the time in the link and that gives every architecture
> > that implements their own show_mem() a link failure because of the
> > double definition. Library linking works at the file level, not at
> > the
> > function level. To work, you have to put these functions in separate
>
> Can't this be fixed by making show_mem() weak ? Or am I missing
> something ?
Yes, I think so; there are multiple ways of solving this ... part of the
point I was making was that there's little point having something in
lib.a if it always gets linked (which this will because of the multiple
callsites for __show_mem())
James
prev parent reply other threads:[~2011-03-25 14:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-23 16:41 Link breakage on all architectures which implement their own show_mem James Bottomley
2011-03-24 22:21 ` David Rientjes
2011-03-25 14:13 ` James Bottomley
2011-03-25 20:02 ` David Rientjes
2011-03-25 18:38 ` Josh Boyer
2011-03-25 10:55 ` Benjamin Herrenschmidt
2011-03-25 14:11 ` James Bottomley [this message]
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=1301062279.4073.1.camel@mulgrave.site \
--to=james.bottomley@hansenpartnership.com \
--cc=benh@kernel.crashing.org \
--cc=linux-arch@vger.kernel.org \
--cc=rientjes@google.com \
/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).