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-freebsd10.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.
> > 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.
Chris
_______________________________________________
devel mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/devel
