On 16/01/2019 02:27, Chris Johns wrote:
On 15/1/19 11:31 pm, Sebastian Huber wrote:
On 13/01/2019 23:17, Chris Johns wrote:
On 14/1/19 8:05 am, Chris Johns wrote:
On 11/1/19 4:31 pm, Sebastian Huber wrote:
----- Am 11. Jan 2019 um 0:11 schrieb Chris Johns chr...@rtems.org:
On 10/1/19 11:17 pm, Sebastian Huber wrote:
This patch resulted in this mail report issue:
Your mail to 'build' with the subject
Build Linux: FAILED 6/rtems-epiphany on x86_64-linux-gnu
(epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1)
Is being held until the list moderator can review it for approval.
The reason it is being held:
Message body is too big: 1093190 bytes with a limit of 256 KB
Are you asking for the size limit on the list to be raised?
No, but is this the normal size for a failed report?
It should not be. I will accept the post and then we can see the reason.
The report captures the last part of the build and it looks like the lines in
the section of the libstdc++ library being built are long. The use of full
length hashes in gcc and newlib has increased the path lengths.
I increased the number of lines captured a while ago because the number of cores
being used when building meant distance in the output between the error and the
end of the log can be a long way.
Maybe a smarter parser should be added and just the error logged?
When I look for tool chain build errors I simply go to the end of the log file
and then search backwards for "error:".
There are linker and I think assembler errors which do not work as well ...
https://git.rtems.org/rtems-tools/tree/tester/rt/check.py#n447
Ok, it is not that simple. I guess we have to improve this each time we
see a 1MiB error log context.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
