Build regressions/improvements in v4.1

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Tue, Jun 23, 2015 at 09:50:00AM +0200, Geert Uytterhoeven wrote:
> Hi Russell,
> 
> On Mon, Jun 22, 2015 at 11:18 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Mon, Jun 22, 2015 at 10:52:13PM +0200, Geert Uytterhoeven wrote:
> >> On Mon, Jun 22, 2015 at 10:48 PM, Geert Uytterhoeven
> >> <geert@linux-m68k.org> wrote:
> >> > JFYI, when comparing v4.1[1] to v4.1-rc8[3], the summaries are:
> >> >   - build errors: +44/-7
> >>
> >>   + /home/kisskb/slave/src/arch/arm/mm/dump.c: error:
> >> 'L_PTE_MT_BUFFERABLE' undeclared here (not in a function):  => 81:10
> >>   + /home/kisskb/slave/src/arch/arm/mm/dump.c: error:
> >> 'L_PTE_MT_DEV_CACHED' undeclared here (not in a function):  => 117:10
> >>   + /home/kisskb/slave/src/arch/arm/mm/dump.c: error:
> >> 'L_PTE_MT_DEV_NONSHARED' undeclared here (not in a function):  =>
> >> 108:10
> >
> > I'm rather ignoring this because I don't see these errors here.  This
> > is one of the problems of just throwing out build reports.  With zero
> > information such as a configuration or a method on how to cause the
> > errors, it's pretty much worthless to post errors.
> >
> > Folk who do build testing need to be smarter, and consider what it's
> > like to be on the receiving end of their report emails...
> 
> Fortunately the kisskb service has good bookkeeping of build logs and configs.

As any good build system should do... :)

> Re-adding the lost URL:
> >> [1] http://kisskb.ellerman.id.au/kisskb/head/9038/ (all 254 configs)
> 
>   1. Open URL in web browser,
>   2. Click on "Failed", next to "arm-randconfig",
>   3. Click on "Download", next to "arm-randconfig",
>   4. Reproduce,
>   5. Fix,
>   6. Profit! ;-)

Looking at the last 7 build results...

That shows that many of the "linus" failing build results are down to:

cc1: error: unrecognized command line option '-fstack-protector-strong'

	which is a compiler/kbuild problem.  The kernel build system checks
	for the flag and warns over it:

	ifdef CONFIG_CC_STACKPROTECTOR_STRONG
	  stackp-flag := -fstack-protector-strong
	  ifeq ($(call cc-option, $(stackp-flag)),)
	    $(warning Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: \
	              -fstack-protector-strong not supported by compiler)
	  endif
	else
	  # Force off for distro compilers that enable stack protector by default.
	  stackp-flag := $(call cc-option, -fno-stack-protector)
	endif

	but this doesn't stop the build progressing - and in any case, it
	shows that randconfig with an outdated compiler is a problem with
	modern Kbuild.  That accounts for 3 of the 7 Linus build failures.

.config:19:warning: symbol value '' invalid for PHYS_OFFSET

	which can't be fixed: it has to be given a value.  That's a
	randconfig problem.

/opt/cross/gcc-4.6.3-nolibc/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-geabi-ld: no machine record defined

	Probably another toolchain problem.

arch/arm/mm/built-in.o:(.proc.info.init+0x198): undefined reference to `fa_user_fns'

	This looks like it's been there for years (since 2009...) but
	needs fixing (and we should probably fix it in a generic way.)

/tmp/ccA1GNig.s:671: Error: selected processor does not support Thumb mode `mrs r6,cpsr'

	Maybe Uwe can investigate this one - it's EFM32 related.

Looking at the linux-next builds:

.config:21:warning: symbol value '' invalid for PHYS_OFFSET
cc1: error: unrecognized command line option '-fstack-protector-strong'

	See above.

drivers/dma/pxa_dma.c:192:2: error: void value not ignored as it ought to be

	Relatively new driver...

eeprom.c:(.text+0x26ad0): undefined reference to `pci_ioremap_io'
pci.c:(.init.text+0x518): undefined reference to `pci_ioremap_io'
last.c:(.text+0xb9fb0): undefined reference to `clk_set_parent'

	Probably drivers not correctly checking their dependencies.

include/linux/virtio_ring.h:45:3: error: implicit declaration of function 'dma_wmb' [-Werror=implicit-function-declaration]

	virtio_ring.h not including a required header file?

As for the build errors you're reporting, that doesn't seem to be
anything new.  It seems to be down to a missing dependency between
ARM_PTDUMP and MMU, which means that ARM_PTDUMP is selectable on !MMU
systems.  I'll add that dependency, but that's just a small drop in
the ocean - it looks like it's the least of the problems with ARM
randconfig...

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.