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 Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
