Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: m68k allmodconfig build errors
To:     Finn Thain <fthain@telegraphics.com.au>
Cc:     Andreas Schwab <schwab@linux-m68k.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Geert Uytterhoeven <geert@linux-m68k.org>,
        linux-m68k@lists.linux-m68k.org
References: <28ebe45d-3dbd-2a82-f537-b0725f7a2bcf@infradead.org>
 <878t66idai.fsf@igel.home>
 <94dc0357-10d4-c3dc-ef2a-9643f08d2a09@infradead.org>
 <alpine.LNX.2.21.1807241423000.8@nippy.intranet>
From:   Randy Dunlap <rdunlap@infradead.org>
Message-ID: <761399f0-0b10-716c-1e80-cfb19c06e455@infradead.org>
Date:   Thu, 26 Jul 2018 12:29:10 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <alpine.LNX.2.21.1807241423000.8@nippy.intranet>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 07/23/2018 09:49 PM, Finn Thain wrote:
> On Mon, 23 Jul 2018, Randy Dunlap wrote:
> 
>> On 07/20/2018 12:20 AM, Andreas Schwab wrote:
>>> On Jul 19 2018, Randy Dunlap <rdunlap@infradead.org> wrote:
>>>
>>>> block/partitions/ldm.o: In function `ldm_partition':
>>>> ldm.c:(.text+0x1900): undefined reference to `strcmp'
>>>> ldm.c:(.text+0x1964): undefined reference to `strcmp'
>>>> drivers/rtc/rtc-proc.o: In function `is_rtc_hctosys':
>>>> rtc-proc.c:(.text+0x290): undefined reference to `strcmp'
>>>> drivers/watchdog/watchdog_pretimeout.o: In function `watchdog_register_governor':
>>>> (.text+0x142): undefined reference to `strcmp'
>>>
>>> GCC has optimized strncmp to strcmp, but at a stage where macros are no
>>> longer available.  I think the right fix is to use strcmp directly,
>>> since strncmp doesn't make sense here.
>>
>> Hi Andreas,
>>
>> I don't see that all of these string compare fields are null-terminated.
>>
> 
> Some of the strncmp calls in ldm.c are null-terminated, some are not. 
> 
> That would imply that the compiler will emit both strcmp and strncmp 
> calls.
> 
> A strncmp call isn't a problem, because m68k doesn't define 
> __HAVE_ARCH_STRNCMP and so the one from lib/string.c gets built.
> 
>> How does one convert strncmp() users to strcmp()?
>>
>> thanks,
>>
> 
> The untested patch below may work. It seems that it may be relevant to 
> both arc and m68k:


I got back to looking at the build errors.  I agree with Andreas that
all of the fields in question are null-terminated, so Finn's patch looks
good to me.


-- 
~Randy