From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1034939AbcIWVRA (ORCPT ); Fri, 23 Sep 2016 17:17:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39900 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1034655AbcIWVQ5 (ORCPT ); Fri, 23 Sep 2016 17:16:57 -0400 Date: Fri, 23 Sep 2016 16:16:55 -0500 From: Josh Poimboeuf To: Linus Torvalds Cc: Michal Marek , Ingo Molnar , Arnaldo Carvalho de Melo , Linux Kernel Mailing List Subject: Re: new objtool warnings again... Message-ID: <20160923211655.d2ho4aguyzgvbl3t@treble> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 23 Sep 2016 21:16:57 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 23, 2016 at 02:06:03PM -0700, Linus Torvalds wrote: > On Fri, Sep 23, 2016 at 1:33 PM, Linus Torvalds > wrote: > > > > So this code is clearly missing the magic to tell gcc that the asm > > needs a frame pointer. > > Independently of that, the objtool build seems racy or somehow > fragile. I've now twice gotten into a situation where I end up getting > > cat: /home/torvalds/v2.6/linux/tools/objtool/.fixdep.o.d: No such > file or directory > make[4]: *** [/home/torvalds/v2.6/linux/tools/objtool/fixdep.o] Error 1 > make[3]: *** [/home/torvalds/v2.6/linux/tools/objtool/fixdep-in.o] Error 2 > make[2]: *** [fixdep] Error 2 > make[1]: *** [objtool] Error 2 > make: *** [tools/objtool] Error 2 > > with just the right timings, and then ccache ends up remembering that > as a build failure and causing that to be "sticky" even across "git > clean -dqfx" builds (and the "ccache -C" clears it). > > Adding Michal to the cc, in case he can see what the problem is. I just started seeing this problem today. I suspect it's a ccache issue, since it only showed up after ccache was updated. I "fixed" it with: yum downgrade ccache I'll open a bug... -- Josh