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 <j...@rtems.org> wrote: On Fri, Jun 18, 2021 at 8:33 AM Matthew Joyce <mfjoyce2...@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 >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
