On Mon, Nov 28, 2016 at 5:32 PM, Chris Johns <[email protected]> wrote:
> On 29/11/2016 09:58, Joel Sherrill wrote: > >> On Mon, Nov 28, 2016 at 3:49 PM, Chris Johns <[email protected] >> <mailto:[email protected]>> wrote: >> >> On 27/11/2016 11:36, Joel Sherrill wrote: >> >> On Nov 26, 2016 6:48 PM, "Chris Johns" <[email protected] >> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> wrote: >> > >> > On 26/11/16 4:02 am, Joel Sherrill wrote: >> > > This has had great support from the gdb developers. >> > >> > Yes the turn around time for this fix was excellent. >> > >> > > >> > > Did any of the other targets show an issue? >> > > >> > >> > I do not know. I have built sparc tools with the patch. I do >> not know if >> > it was also broken. >> >> This was a build error so we need to build all the tools on >> FreeBSD to >> check. >> >> >> I built 4.12/rtems-all on FreeBSD and the following failed: >> >> epiphany-rtems4.12-gdb-7.8.1-x86_64-freebsd10.3-1 >> m32c-rtems4.12-gdb-7.9-x86_64-freebsd10.3-1 >> mips-rtems4.12-gcc-6-20161110-newlib-2.4.0.20161025-x86_64-f >> reebsd10.3-1 >> mipstx39-rtems4.12-gdb-7.9-x86_64-freebsd10.3-1 >> >> The issues are: >> >> epiphany-rtems4.12-gdb: >> m32c-rtems4.12-gdb-7.9: >> mipstx39-rtems4.12-gdb-7.9: >> - libiconv issue >> >> I don't recall this one. >> >> > I suspect libiconv support needs a path or a library for some versions. > The complication is iconv support changed with FreeBSD v10. This means the > generic gdb build recipe may need help to be taught how to do this. > > mips-rtems4.12-gcc-6-20161110-newlib-2.4.0.20161025: >> - BSD shell issue in the expansion of the multilibs. >> >> We have emailed/filed/discussed this before with the GCC folks. >> The resolution was to use GNU sed. >> > > Yes I remember. > > They were not willing to >> rewrite the t-* fragment to use BSD sed and GNU sed. >> > > This is an unfortunate situation and it creates a negative feeling towards > the gcc project. I would like to know if the cause is the result of a > non-standards based feature in the GNU sed. > > Unless we find a sed expert, this is the solution. >> > > It is not sed I had the problem with, it was the expected output. It > requires knowledge of the expected MIUPS mult-libs. Plus I found the gcc > build system with this stuff difficult to debug and see what the issue > actually is. Ping the GCC Pr and see if Richard Sandiford can at least provide example input and output. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62097 > > > > I think this got applied to the 7.12 branch and master, >> right? >> > >> > Sorry, I do not know. I think this patch should be pushed >> until a >> > release with the fix is available. Ok to push? >> >> I thought they put it on both but we need the patch so push what >> is >> needed for 7.12. >> >> >> They may have however I am not sure what you are asking. >> >> RTEMS has to use 7.12 as is with what patches we need. When 7.12.1 is >> out, we should jump to that. >> > > Yes, however it is not clear to me if you are saying wait for that or can > this patch be pushed? I do not think I have seen a clear OK to push, I may > have missed it. > > Push it. :) > Chris >
_______________________________________________ devel mailing list [email protected] http://lists.rtems.org/mailman/listinfo/devel
