[lkml]   [2010]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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 <> 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/
    >>> In file included from scripts/kconfig/
    >>> 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.


     \ /
      Last update: 2010-10-27 23:23    [W:0.023 / U:9.300 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site