[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4CC89781.4000309@suse.cz>
Date: Wed, 27 Oct 2010 23:20:01 +0200
From: Michal Marek <mmarek@...e.cz>
To: Arnaud Lacombe <lacombar@...il.com>
Cc: Christoph Hellwig <hch@...radead.org>,
Stephen Rothwell <sfr@...b.auug.org.au>,
linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
Zimny Lech <napohybelskurwysynom2010@...il.com>
Subject: Re: linux-next: Tree for October 20
On 26.10.2010 18:22, Arnaud Lacombe wrote:
> Hi,
>
> On Mon, Oct 25, 2010 at 4:47 AM, Michal Marek <mmarek@...e.cz> wrote:
>> On 21.10.2010 15:09, Christoph Hellwig wrote:
>>> I can't even get the required userspace code make oldconfig to compile:
>>>
>>> hch@...ck:~/work/linux-2.6/obj-kvm$ make oldconfig
>>> make -C /home/hch/work/linux-2.6 O=/home/hch/work/linux-2.6/obj-kvm/. oldconfig
>>> GEN /home/hch/work/linux-2.6/obj-kvm/Makefile
>>> HOSTCC scripts/kconfig/zconf.tab.o
>>> In file included from scripts/kconfig/zconf.tab.c:2481:
>>> scripts/kconfig/lex.zconf.c:2425: error: conflicting types for 'zconf_curname'
>>> /home/hch/work/linux-2.6/scripts/kconfig/lkc.h:79: note: previous declaration of 'zconf_curname' was here
>>> scripts/kconfig/lex.zconf.c: In function 'zconf_curname':
>>> scripts/kconfig/lex.zconf.c:2427: warning: return discards qualifiers from pointer target type
>>
>> The zconf_curname() prototype was changed in 2e7a091 and the
>> scripts/kconfig/lex.zconf.c_shipped file was updated as well. What
>> probably happened is that you ended up using an updated
>> scripts/kconfig/lkc.h header versus an old version of
>> scripts/kconfig/lex.zconf.c. Ie. the rule that copies
>> scripts/kconfig/lex.zconf.c_shipped to scripts/kconfig/lex.zconf.c did
>> not trigger, very strange. I'll look further.
>>
> this is at least the third time there is such a report. I did
> reproduce this issue while using an external build directory:
>
> From what I remind:
>
> % gmake menuconfig # generate lex.zconf.c
> % gmake O=/foo menuconfig # generate lex.zconf.c
>
> % touch scripts/kconfig/lex.zconf.c_shipped
>
> % gmake menuconfig # re-generated lex.zconf.c
> % gmake O=/foo menuconfig # did _not_ re-generate lex.zconf.c
OK, if you mix O= and non-O= builds then things can break in various
ways. That's why the top-level Makefile tries to detect this and abort,
unfortunately the check is not strict enough (it checks for the presence
of include/config/kernel.release, which is not created yet when you run
make *config). Christoph, is it possible that your case was the same,
ie. that you had run make *config in the source tree before?
In that case, I'd like to skip this bug for 2.6.37-rc1, because 1) it's
a user error, 2) Linus shortened the merge window and last-minute
changes to the top-level Makefile can cause more harm and good, 3) I
have flu and I only check my mail occasionally this week, so the less
stuff to deal with, the better :). I'll come up with a fix for -rc2 or so.
Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists