On Wed, Dec 14, 2016 at 05:45:39PM +0000, Mark Brown wrote:
Date: Wed, 14 Dec 2016 17:45:39 +0000 From: Mark Brown broonie@kernel.org To: Ralf Baechle ralf@linux-mips.org Cc: kernel-build-reports@lists.linaro.org, linux-mips@linux-mips.org Subject: Re: next build: 198 builds: 4 failed, 194 passed, 7 errors, 82 warnings (next-20161214) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pme7352aoyqgs7t5"
On Wed, Dec 14, 2016 at 05:06:09PM +0100, Ralf Baechle wrote:
On Wed, Dec 14, 2016 at 01:52:14PM +0000, Mark Brown wrote:
On Wed, Dec 14, 2016 at 12:39:18AM -0800, kernelci.org bot wrote:
mips: gcc version 5.3.0 (Sourcery CodeBench Lite 2016.05-8)
These MIPS builds have been failing in kernelci ever since MIPS was added. This means that we've got a constant level of noise in the results which makes them less useful for everyone - people get used to ignoring errors. Is there any plan to get these fixed?
I wonder if these are also toolchain-related issues. allnoconfig and tinyconfig do build fine for me with GCC 6.1.0 and binutils 2.26.20160125.
generic_defconfig requires mkimage of uboot-tools or it will fail like this:
ITB arch/mips/boot/vmlinux.gz.itb "mkimage" command not found - U-Boot images will not be built arch/mips/boot/Makefile:159: recipe for target 'arch/mips/boot/vmlinux.gz.itb' failed make[1]: *** [arch/mips/boot/vmlinux.gz.itb] Error 1 arch/mips/Makefile:365: recipe for target 'vmlinux.gz.itb' failed make: *** [vmlinux.gz.itb] Error 2
Ah, you don't have a separate uImage target?
What binutils are you using and can you send me the build errors messages?
You can see logs for all the trees we build via the web interface:
I don't have access to the builders to check the binutils version without going and finding/downloading the CodeSourcery release. Where did your toolchain come from, is there something specific recommended for MIPS?
I specifically avoid non-standard toolchains, that is I stick to the vanilla FSF releases with no feature patches.
Some configurations, in particular new cores or architecture variants may require vendor tool- chains or patches until support makes it upstream. I wonder if for the benefit of automated build testing we should tag kernel configurations with a special CONFIG_ symbol to indicate they need non-standard tools? That would allow build testing to detect and possibly skip such configuration.
Ralf