GSoC POSIX Compliance: Can't Build RTEMS Tool Suite Anymore

[Matthew Joyce]

Thanks for your note, Sir! I'll never get that day back, but I'm glad to be
back on track now and have made
a bit of progress.

I made the change locally in libc/sys/signal.h to use the *__restrict. I
then configured and (successfully!)
built newlib for sparc-rtems6. I see the various build binaries in the
b-sparc-rtems6-newlib directory. I nm
them for the newly declared functions, for example: sparc-rtems6-nm
<example>/libc.a | grep sig2str but
they don't show up at all. Would symbols show up in the binaries after
being declared (but not defined)?
Where do I go from here to ensure this prototype patch is good to go to
submit to Newlib?

Also, you wrote:
"...as long as you are working on patches to newlib, it is simpler and much
quicker to just build newlib
and install it over the RSB built version. You do not need to rebuild gcc,
binutils, or gdb."

Could you please elaborate on what you mean by "just build newlib and
install it over the RSB built version"?

Thank you very much for your time!

Sincerely,

Matt


On Jun 18, 2021, at 5:17 PM, Joel Sherrill <joel at rtems.org> wrote:




On Fri, Jun 18, 2021 at 8:33 AM Matthew Joyce <mfjoyce2004 at gmail.com> wrote:

> Dear Mentors,
>
> I'm sorry to report that I've taken one step forward and three steps
> back. Since last night, I'm having trouble building the RTEMS tool
> suite at all. I keep getting the same error (attached).
>
> Steps I've taken to attempt to resolve:
> 1) Tried to check out previous commits and rebuild from there.
> 2) sudo yum update && upgrade
>

Did the native gcc or binutils update? The failure looks like an assembler
issue with gcc output but weird since it is a partial line error. Did you
run out of disk space?


> 3) Followed the quick-start guide from scratch (clone rsb and source
> into a new development directory, still fails in 2.4, Install the tool
> suite).
>
> How I got here: I applied my initial header patch to rsb using the
> blog guide and rebuilt the tool set. It built successfully, but then
> failed when I ran waf. (Compiler had issues with my use of the keyword
> "restrict".) I then created a new patch without "restrict", just to
> see if it would compile.


__restrict is what I hope you used and not just restrict. newlib uses
the __restrict macro it defines to ensure it only uses the restrict keyword
when it is supported by the language standard version being compiled with.


> I deleted the old patch from the
> tools/rtems-gcc-10-newlib-head.cfg and put the new one in.
>
> I'm guessing that was not correct based on my experience of the last 15
> hours!
>

You have to eventually deal with the RSB but as long as you are working
on patches to newlib, it is simpler and much quicker to just build newlib
and install it over the RSB built version. You do not need to rebuild gcc,
binutils, or gdb.

With the locally updated newlib, make changes to your local RTEMS
to add methods and/or tests.

When the newlib side is ready, submit the patch for review. When that
is merged, the newlib version in the RSB will need to be bumped.
After the newlib RSB hash is bumped, then things are in place to submit
your RTEMS modifications.

Streamlining the build/test cycle like this may save an hour an iteration.

You usually can't submit a newlib change and a corresponding RTEMS
change in parallel anyway. They have to be sequenced because of the
dependency.


>
> I'm really looking forward to your feedback and advice when you can.
> Thank you again!
>
> Sincerely,
>
> Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210619/6f5ded7e/attachment-0001.html>