[meta-freescale] building core-image-minimal fort1042d4rdb* failsbuilding hypervisor

[Robert P. J. Day]

On Sun, 9 Jul 2017, Kursad Oney CW wrote:

> Robert,
>
> >   to make a long story (hopefully) short, i was trying to build both
> > the 32- and 64-bit versions of t1042d4rdb, and both failed in exactly
> > the same place, trying to build the hypervisor recipe, so i'm open to
> > suggestions (this is on a fully-updated fedora system):
> >
> > [...truncated...]
> > | /home/rpjday/oe/builds/t1042d4rdb-64b/tmp/work/ppc64e5500-poky-linux/hypervisor/git-r3/git/libos/lib/sprintf.c: In function 'sprintf':
> > | /home/rpjday/oe/builds/t1042d4rdb-64b/tmp/work/ppc64e5500-poky-linux/hypervisor/git-r3/git/libos/lib/sprintf.c:459:6: error: specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Werror=format-truncation=]
> > |   int ret = vsnprintf(buf, ULONG_MAX, str, args);
> > |       ^~~
> > | cc1: all warnings being treated as errors
>
> I think gcc is complaining about ULONG_MAX being the size argument.
> Since vsnprintf() returns int, it can print at most LONG_MAX characters to
> the buffer. I'd probably just change that argument to LONG_MAX.
>
> I believe the format-truncation flag is a gcc 7 thing.

  i suspected as much, but i'm curious as to why this error still
exists, and wasn't flagged by regular build testing. i don't just want
to hack the code without hearing from others as to why this issue
exists.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================