From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Nicholas A. Bellinger" Subject: Re: [-next] ERROR: "strchr" [drivers/target/target_core_mod.ko] undefined! Date: Fri, 07 Jan 2011 13:04:34 -0800 Message-ID: <1294434274.2895.146.camel@haakon2.linux-iscsi.org> References: <1294415045.4895.16.camel@mulgrave.site> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: Received: from mail.linux-iscsi.org ([67.23.28.174]:49176 "EHLO linux-iscsi.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752425Ab1AGVKd (ORCPT ); Fri, 7 Jan 2011 16:10:33 -0500 In-Reply-To: <1294415045.4895.16.camel@mulgrave.site> Sender: linux-next-owner@vger.kernel.org List-ID: To: James Bottomley Cc: Geert Uytterhoeven , scsi , Linux-Next , linux-kernel@vger.kernel.org On Fri, 2011-01-07 at 09:44 -0600, James Bottomley wrote: > On Fri, 2011-01-07 at 11:57 +0100, Geert Uytterhoeven wrote: > > Since a few days, linux-next shows: > > > > | ERROR: "strchr" [drivers/target/target_core_mod.ko] undefined! > > > > in m68k allmodconfig builds > > (http://kisskb.ellerman.id.au/kisskb/buildresult/3754323/). > > > > I guess this is caused by the following 3 calls to strstr(): > > > > drivers/target/target_core_configfs.c: > > + ptr = strstr(page, "1"); > > > > + str = strstr(buf, "_"); > > > > + str2 = strstr(str+1, "_"); > > > > Some versions of gcc replace calls to strstr() with single-character > > "needle" string parameters by calls to strchr() behind our back. > > This causes linking errors if strchr() is defined as an inline function > > in (e.g. on m68k). > > > > You can prevent this by explicitly calling strchr() instead. > > > > Cfr. commit 59d309f9c8ef0bd01bf93cc0e758f1d810417bdb > > ("kgdb: Replace strstr() by strchr() for single-character needles). > > > > Gr{oetje,eeting}s, > > Surely the fix for this is not to inline it in m68k? If gcc is growing > the capability to make these types of transformations, it's not going to > stop at single entry string strstr(). > > If you want to keep the fast inline, there is a way (which I forget) to > drop an external reference as well, just in case. > Hi guys, So I really don't have a strong perference here, but would tend to agree with James that this should probably be fixed in m68k.. If this is too much of an pain for you Geert I am happy to make this change. Thanks! --nab