Re: parisc:generic-64bit_defconfig build failures due to 'kbuild: handle libs-y archives separately...'

From: Fengguang Wu
Date: Tue Jul 18 2017 - 22:10:27 EST


On Wed, Jul 19, 2017 at 12:01:06PM +1000, Nicholas Piggin wrote:
On Tue, 18 Jul 2017 23:58:07 +0200
Helge Deller <helge.deller@xxxxxxxxxxxxxxxxxxxxxxx> wrote:


This outstanding patch will fix it:
https://patchwork.kernel.org/patch/9832033/
HelgeÂ
Von meinem Samsung GerÃt gesendet.

Thanks for the quick fix. I'm not sure why 0day didn't catch it.
Does it build test parisc/generic-64bit_defconfig, I wonder?

We do test that config. I guess it's because the build servers are
under pressure recently. Philip/Xiaolong are looking at this issue.

Thanks,
Fengguang

-------- UrsprÃngliche Nachricht --------
Von: Guenter Roeck <linux@xxxxxxxxxxxx>
Datum: 18.07.17 17:21 (GMT+01:00)
An: Nicholas Piggin <npiggin@xxxxxxxxx>
Cc: linux-kernel@xxxxxxxxxxxxxxx, Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>, "James E.J. Bottomley" <jejb@xxxxxxxxxxxxxxxx>, Helge Deller <deller@xxxxxx>, linux-parisc@xxxxxxxxxxxxxxx
Betreff: parisc:generic-64bit_defconfig build failures due to 'kbuild: handle
libs-y archives separately...'

Hi,

parisc64 builds, specifically generic-64bit_defconfig, fail to build
in mainline as follows.

hppa64-linux-ld:
hppa64-linux/bin/../lib/gcc/hppa64-linux/4.9.0/libgcc.a(_divdi3.o)(.text+0xec):
cannot reach $$divU
hppa64-linux/bin/../lib/gcc/hppa64-linux/4.9.0/libgcc.a(_divdi3.o):
In function `__divdi3':
libgcc2.c:(.text+0xec): relocation truncated to fit: R_PARISC_PCREL22F against
symbol `$$divU' defined in .text.div section in
hppa64-linux/bin/../lib/gcc/hppa64-linux/4.9.0/libgcc.a(_divU.o)
hppa64-linux-ld:
hppa64-linux/bin/../lib/gcc/hppa64-linux/4.9.0/libgcc.a(_divdi3.o)(.text+0x150):
cannot reach $$divU

[ and many more ]

This is after enabling CONFIG_MLONGCALLS; otherwise build failures are
more severe.

Building with gcc 6.3.0 fails as well with the same error.

Bisect points to commit 3a166fc2d4ef ("kbuild: handle libs-y archives
separately from built-in.o archives") as the culprit. Bisect log is
attached.