login
Search
Hi all, Changes since 20101019: The arm tree lost its conflicts. The s5p tree lost its merge fix patch. The v4l-dvb tree still has a build failure for which I applied a patch. The drm tree lost its conflict. The security-testing tree lost its build failure but gained another for which I applied a patch. The tip tree lost its build failure. The swiotlb-xen tree gained a conflict against the pci tree. ---------------------------------------------------------------------------- I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/v2.6/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc and sparc64 defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 176 trees (counting Linus' and 22 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more ...
linux-next-20101020/drivers/xen/biomerge.c: In function 'xen_biovec_phys_mergeable': linux-next-20101020/drivers/xen/biomerge.c:8: error: dereferencing pointer to incomplete type linux-next-20101020/drivers/xen/biomerge.c:9: error: dereferencing pointer to incomplete type linux-next-20101020/drivers/xen/biomerge.c:11: error: implicit declaration of function '__BIOVEC_PHYS_MERGEABLE' config is attached. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code ***
Ok, this patch fixes it. I am sticking it in my tree: From 2d7d06dd8ffcbafc03bf2c1cb4b2fb2c4c405ec1 Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Wed, 20 Oct 2010 13:04:13 -0400 Subject: [PATCH] xen: Update Makefile with CONFIG_BLOCK dependency for biomerge.c Without this dependency we get these compile errors: linux-next-20101020/drivers/xen/biomerge.c: In function 'xen_biovec_phys_mergeable': linux-next-20101020/drivers/xen/biomerge.c:8: error: dereferencing pointer to incomplete type linux-next-20101020/drivers/xen/biomerge.c:9: error: dereferencing pointer to incomplete type linux-next-20101020/drivers/xen/biomerge.c:11: error: implicit declaration of function '__BIOVEC_PHYS_MERGEABLE' Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> --- drivers/xen/Makefile | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile index b47f5da..b978645 100644 --- a/drivers/xen/Makefile +++ b/drivers/xen/Makefile @@ -1,9 +1,10 @@ -obj-y += grant-table.o features.o events.o manage.o biomerge.o +obj-y += grant-table.o features.o events.o manage.o obj-y += xenbus/ nostackp := $(call cc-option, -fno-stack-protector) CFLAGS_features.o := $(nostackp) +obj-$(CONFIG_BLOCK) += biomerge.o obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o obj-$(CONFIG_XEN_XENCOMM) += xencomm.o obj-$(CONFIG_XEN_BALLOON) += balloon.o -- --
-- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** --
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 I'm compiling on 32-bit x86, using: gcc version 4.4.5 20100728 (prerelease) (Debian 4.4.4-8) --
I had a similar problem, mrproper solved it -- Slawa! N.P.S. Les fleurs du mal unfold Comme les fleurs du mal Dark demons of my soul Un amour fatal --
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. Michal --
Hi, 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 However, this tree was dirty (ie. included WIP stuff), switching to a clean tree, and certainly updating a bunch of timestamps, make it disappear. - Arnaud --
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 --
