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
========================================================================
--
_______________________________________________
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
