Re: next build: 198 builds: 4 failed, 194 passed, 7 errors, 82 warnings (next-20161214)

[Ralf Baechle <ralf@linux-mips.org>]

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:
> 
>    https://kernelci.org/job/
> 
> 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