On 26.10.2010 18:22, Arnaud Lacombe wrote: > Hi, > > On Mon, Oct 25, 2010 at 4:47 AM, Michal Marek <mmarek@xxxxxxx> wrote: >> On 21.10.2010 15:09, Christoph Hellwig wrote: >>> I can't even get the required userspace code make oldconfig to compile: >>> >>> hch@brick:~/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-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
