All of lore.kernel.org
 help / color / mirror / Atom feed
* Link breakage on all architectures which implement their own show_mem
@ 2011-03-23 16:41 James Bottomley
  2011-03-24 22:21 ` David Rientjes
  2011-03-25 10:55 ` Benjamin Herrenschmidt
  0 siblings, 2 replies; 7+ messages in thread
From: James Bottomley @ 2011-03-23 16:41 UTC (permalink / raw)
  To: David Rientjes; +Cc: linux-arch

This is the problem a lot of architectures will see:

Specifically this:
  LD      vmlinux.o
lib/lib.a(show_mem.o): In function `show_mem':
(.text.show_mem+0x0): multiple definition of `show_mem'
arch/parisc/mm/built-in.o:(.text.show_mem+0x0): first defined here
make: *** [vmlinux.o] Error 1

Caused by this patch:

commit ddd588b5dd55f14320379961e47683db4e4c1d90
Author: David Rientjes <rientjes@google.com>
Date:   Tue Mar 22 16:30:46 2011 -0700

    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
files.

James

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Link breakage on all architectures which implement their own show_mem
  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 18:38   ` Josh Boyer
  2011-03-25 10:55 ` Benjamin Herrenschmidt
  1 sibling, 2 replies; 7+ messages in thread
From: David Rientjes @ 2011-03-24 22:21 UTC (permalink / raw)
  To: James Bottomley; +Cc: linux-arch

On Wed, 23 Mar 2011, James Bottomley wrote:

> This is the problem a lot of architectures will see:
> 
> Specifically this:
>   LD      vmlinux.o
> lib/lib.a(show_mem.o): In function `show_mem':
> (.text.show_mem+0x0): multiple definition of `show_mem'
> arch/parisc/mm/built-in.o:(.text.show_mem+0x0): first defined here
> make: *** [vmlinux.o] Error 1
> 
> Caused by this patch:
> 
> commit ddd588b5dd55f14320379961e47683db4e4c1d90
> Author: David Rientjes <rientjes@google.com>
> Date:   Tue Mar 22 16:30:46 2011 -0700
> 
>     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
> files.
> 

Thanks for the report, James.

This was also reported by Stephen on LKML when he merged the latest Linus 
tree into linux-next.  Andrew suggested that we remove __show_mem() 
entirely and simply add its argument to show_mem() in all the 
architectures.  I have a patch at:

	http://marc.info/?l=linux-kernel&m=130100511521954

I don't have a parisc cross compiler, so if you could try it out and add 
your Tested-by that would be great

Thanks again!

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Link breakage on all architectures which implement their own show_mem
  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 10:55 ` Benjamin Herrenschmidt
  2011-03-25 14:11   ` James Bottomley
  1 sibling, 1 reply; 7+ messages in thread
From: Benjamin Herrenschmidt @ 2011-03-25 10:55 UTC (permalink / raw)
  To: James Bottomley; +Cc: David Rientjes, linux-arch

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 ?

Cheers,
Ben.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Link breakage on all architectures which implement their own show_mem
  2011-03-25 10:55 ` Benjamin Herrenschmidt
@ 2011-03-25 14:11   ` James Bottomley
  0 siblings, 0 replies; 7+ messages in thread
From: James Bottomley @ 2011-03-25 14:11 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: David Rientjes, linux-arch

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Link breakage on all architectures which implement their own show_mem
  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
  1 sibling, 1 reply; 7+ messages in thread
From: James Bottomley @ 2011-03-25 14:13 UTC (permalink / raw)
  To: David Rientjes; +Cc: linux-arch

On Thu, 2011-03-24 at 15:21 -0700, David Rientjes wrote:
> I don't have a parisc cross compiler, so if you could try it out and add 
> your Tested-by that would be great

I'm afraid this hit at exactly the wrong time (we're relocating the
parisc dev cluster in cupertino), so all my parisc build systems are
currently trekking across country on fedex mules.

James

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Link breakage on all architectures which implement their own show_mem
  2011-03-24 22:21 ` David Rientjes
  2011-03-25 14:13   ` James Bottomley
@ 2011-03-25 18:38   ` Josh Boyer
  1 sibling, 0 replies; 7+ messages in thread
From: Josh Boyer @ 2011-03-25 18:38 UTC (permalink / raw)
  To: David Rientjes; +Cc: James Bottomley, linux-arch

On Thu, Mar 24, 2011 at 6:21 PM, David Rientjes <rientjes@google.com> wrote:
> On Wed, 23 Mar 2011, James Bottomley wrote:
>
>> This is the problem a lot of architectures will see:
>>
>> Specifically this:
>>   LD      vmlinux.o
>> lib/lib.a(show_mem.o): In function `show_mem':
>> (.text.show_mem+0x0): multiple definition of `show_mem'
>> arch/parisc/mm/built-in.o:(.text.show_mem+0x0): first defined here
>> make: *** [vmlinux.o] Error 1
>>
>> Caused by this patch:
>>
>> commit ddd588b5dd55f14320379961e47683db4e4c1d90
>> Author: David Rientjes <rientjes@google.com>
>> Date:   Tue Mar 22 16:30:46 2011 -0700
>>
>>     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
>> files.
>>
>
> Thanks for the report, James.
>
> This was also reported by Stephen on LKML when he merged the latest Linus
> tree into linux-next.  Andrew suggested that we remove __show_mem()
> entirely and simply add its argument to show_mem() in all the
> architectures.  I have a patch at:
>
>        http://marc.info/?l=linux-kernel&m=130100511521954
>
> I don't have a parisc cross compiler, so if you could try it out and add
> your Tested-by that would be great

You can find basic cross compilers for a variety of architectures
already built here:

http://www.kernel.org/pub/tools/crosstool/

josh

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Link breakage on all architectures which implement their own show_mem
  2011-03-25 14:13   ` James Bottomley
@ 2011-03-25 20:02     ` David Rientjes
  0 siblings, 0 replies; 7+ messages in thread
From: David Rientjes @ 2011-03-25 20:02 UTC (permalink / raw)
  To: James Bottomley; +Cc: linux-arch

On Fri, 25 Mar 2011, James Bottomley wrote:

> > I don't have a parisc cross compiler, so if you could try it out and add 
> > your Tested-by that would be great
> 
> I'm afraid this hit at exactly the wrong time (we're relocating the
> parisc dev cluster in cupertino), so all my parisc build systems are
> currently trekking across country on fedex mules.
> 

Haha, ok.  Linus merged the patch into his tree so you should hear from 
parisc people if there is additional breakage, which there shouldn't be.  
Thanks again for the report.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2011-03-25 20:02 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.