<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 23, 2019 at 12:22 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Joel,<br>
<br>
On 22/01/2019 23:04, Joel Sherrill wrote:<br>
> Hi<br>
><br>
> I put this on hold for the Christmas holidays and wanted to post what <br>
> worked and didn't for me. This is on Centos 7 building C, C++ and Ada <br>
> to target sparc-rtems5 using the RSB master.<br>
><br>
> I tried various gcc versions with Ada support. I ensured which gcc I <br>
> was using by putting it at the front of my PATH and doing "gcc <br>
> --version" before I started the RSB build.<br>
><br>
> + RSB build fails with base gcc from CentOS. It is gcc 4.8.5<br>
> + RSB build fails with gcc from git master.<br>
> + RSB build fails with gcc 8.2.0<br>
> + RSB build succeeds with gcc 7.4.0<br>
> Notice that the build succeeds when using a native version that <br>
> matches the version being built cross. This is in keeping with <br>
> long-standing advice.<br>
<br>
the current situation for GCC 9 is less good. I was not able to build it <br>
on Debian:<br>
<br>
<a href="https://gcc.gnu.org/ml/gcc/2019-01/msg00141.html" rel="noreferrer" target="_blank">https://gcc.gnu.org/ml/gcc/2019-01/msg00141.html</a><br>
<br>
On openSUSE it worked.<br></blockquote><div><br></div><div>I ended up with a lot of tool fail emails to the build@ mailing list so I wanted</div><div>to come back and summarize.  Using a locally built gcc 7.4.0, I managed</div><div>to build Ada crosses for the following targets using the RSB:</div><div><br></div><div><div>aarch64-rtems5 arm-rtems5 bfin-rtems5 i386-rtems5 m68k-rtems5</div><div>microblaze-rtems5 mips-rtems5 moxie-rtems5 powerpc-rtems5</div><div>sparc64-rtems5 sparc-rtems5 v850-rtems5 x86_64-rtems5</div></div><div><br></div><div>That leaves epiphany, lm32, nios2, or1k, riscv, and sh as not building.</div><div><br></div><div>riscv is using a gcc with a hash so it may be hard to get a gnat</div><div>that matches. Ignoring that since it may settle out in the future.</div><div><br></div><div>sh has always had issues with single precision float and Ada (and Fortran).</div><div><br></div><div>epiphany fails with an error building targetext.c. No reason to think</div><div>anyone cares about this target and Ada anyway. It is likely too</div><div>small to support Ada.</div><div><br></div><div>nios2 also fails building targetext.c. Maybe both it and epiphany are</div><div>not doing something 100% right in the target code.</div><div><br></div><div>or1k is using a gcc hash so again hard to get a matching native gcc.</div><div><br></div><div>In summary, the target code has to really following the rules,</div><div>not having double precision is an issue, and it needs to be on</div><div>a "real" gcc version to be worth building a matching native </div><div>Ada.</div><div><br></div><div>I'm going to disable Ada and enable Fortran and see how that</div><div>goes over the weekend.</div><div><br></div><div>--joel</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone   : +49 89 189 47 41-16<br>
Fax     : +49 89 189 47 41-09<br>
E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
PGP     : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
<br>
</blockquote></div></div></div>