[Buildroot] Analysis results for 2018-10-09

[Thomas Petazzoni <thomas.petazzoni@bootlin.com>]

Hello,

On Thu, 11 Oct 2018 07:43:32 +0300, Baruch Siach wrote:
> Thomas Petazzoni writes:
> >>          arm |                boa-0.94.14rc21 | NOK | http://autobuild.buildroot.net/results/e5ff4589243ce1f11248b5f9fab3cca614a48b11 | ORPH  
> >
> > (cd src && make - --no-print-directory - --jobserver-fds=6,7 -j)
> > make: unrecognized option '--jobserver-fds=6,7'
> >
> > This suddenly started happening on September 9, 2018. We have not
> > bumped boa. I'm not sure what caused this. It fails on different
> > autobuilder machines. Boa is calling submake with $(MFLAGS), which is
> > probably the issue, but why did this suddenly started to happen ?
> >
> > With a minimal configuration with just Boa, I cannot reproduce on my
> > machine here, neither on my autobuilder where the problem is reported
> > to occur.  
> 
> I guess it is related to commit 05167a9ffa (package/make: add host
> variant) which was applied on September 8, 23:36. Build seems to fail
> only on hosts with make older than 4.0, so the host-make build is
> triggered.

Yes, I figured that out after sending my summary. I reproduced the
issue on my build server, which has an old make installed system-wide,
and this issue seems to appear only when host-make is built prior to
boa. There's a mixup of make being used, with a new "make" used at the
top-level, passing options unknown to the old "make" used at the
lower-level.

> This failure is from before my patch bumping squid to 4.3 (commit
> 419c47a2135). But I believe we'll see the same failure with 4.3.
> 
> The build only fails with the CT-NG PowerPC e500 toolchain. Is that the
> only gcc 4.7 toolchain?
> 
> This is the failing code:
> 
> typedef double hbase_f(double);
> 
> class StatHist
> {
>     ...
>     hbase_f *val_in = nullptr;        /* e.g., log() for log-based histogram */
>     hbase_f *val_out = nullptr;       /* e.g., exp() for log based histogram */
> }
> 
> For some reason this version of gcc considers val_in/val_out as
> methods. But "fixing" the problem by changing the assignment to '= 0'
> makes gcc segfault, not even ICE. So I think this is a compiler
> bug. Should squid depend on gcc >= 4.8?

It would be nice to find an actual gcc bug report for this. I very much
prefer to document such issues using BR2_TOOLCHAIN_HAS_GCC_BUG_xyz
dependencies rather than semi-random gcc version dependencies.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com