Thread (6 messages) read the whole thread 6 messages, 2 authors, 2015-06-25

Build regressions/improvements in v4.1

From: Russell King - ARM Linux <hidden>
Date: 2015-06-25 09:18:41
Also in: linux-media, lkml

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
[off-list ref] wrote:
quoted
On Mon, Jun 22, 2015 at 10:52:13PM +0200, Geert Uytterhoeven wrote:
quoted
On Mon, Jun 22, 2015 at 10:48 PM, Geert Uytterhoeven
[off-list ref] wrote:
quoted
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:
quoted
quoted
[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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help