<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Jarielle,
      <br>
      Unfortunately my home linux machine seems to be <b
        class="moz-txt-star"><span class="moz-txt-tag">*</span>really<span
          class="moz-txt-tag">*</span></b> taking along time to build
      <br>
      the tools.  I agree that the steps you took, while they may have
      worked, have other
      <br>
      negative implications.  I didn't have to go through the same steps
      you did.
      <br>
      I don't recall any error with __ctype_ptr__.
      <br>
      <br>
      Did you also change set the library path in the makefile?...
      <br>
      <br>
      # Using RTEMS Source Builder tools:
      <br>
      ABIDIR          =
      $(HOME)/development/rtems/4.11/lib/gcc/arm-rtems4.11/4.9.2
      <br>
      LIBABIDIR       = -L $(ABIDIR)
      <br>
      TOOL_PREFIX     = arm-rtems4.11
      <br>
      <br>
      If my tools build ever completes I'll verify what I did earlier
      today...
      <br>
      Ed
    </div>
    <blockquote
cite="mid:CANjxxd0S2vCW1Hyi18NDtTP-=PCEJNPuuY71rMR_YkRvWUwv5A@mail.gmail.com"
      type="cite">
      <pre wrap="">Ed,

Ok, so the data exception has been removed and now executing any of
the commands can complete successfully.  I built Umon using the
arm-rtems4.11 toolset.

The steps I had to take to successfully build Umon after removing the
__ctype_ptr__ pointers in docmd.c is quite involving and I was able to
reach a solution after several hours of debugging.


I will now elaborate the situation that I underwent:


The first thing that I did was I replaced the arm-none-eabi toolset
with the arm-rtems4.11 toolset in the BBB Makefile.  I next removed
the __ctype_ptr__ pointers from docmd.c.  With that in place, I built
Umon but it failed with the linking process indicating the there was
undefined reference to __ctype_ptr__.


I figured that __ctype_ptr__ is defined in the the C library that came
with the arm-rtems4.11 toolset and so I directly linked to the C
library during the linking process with the file (for me arm-rtems4.11
toolset is installed under 'opt' in my home directory)

$(HOME)/opt/arm-rtems4.11/lib/libc.a


Doing this caused several errors.  The first is that linking this
library also had undefined references.  After some extensive analysis,
these references were defined in $(HOME)/opt/arm-rtems4.11/lib/crt0.o
and as a result I also had to link this file during the linking
process.

The last set of errors were multiple redefinitions.  Since Umon has a
set of internal functions whose names also coincide with those in the
C library, incorporating locally defined functions together with
standard-defined functions by linking the C library resulted in
multiple definition errors.  I rectified these errors by passing the
option "--allow-multiple-defintion" to the linker during the linking
process.

With all of this set in place, I was able to build Umon successfully
with the arm-rtems4.11 toolset and have verified that the images work
on the BBB with no data abort exception occuring.

One thing I'd like to mention is that these mechanisms in place does
not feel natural to me.  One of which is mixing locally defined
functions with standard-defined functions with the same names.
Another is having to specify an option to ignore multiple
redefinitions.  To me this could potentially be error prone if the
order of libraries included defining the same set of functions does
not match the intention of a particular function executing rather than
the other.


As a result, I want to find a more elegant solution.  I am open to
advice and suggestions on how to proceed.


One thing that has occured to me, is that it seems that the same steps
I undertook when setting up Umon to be built with the arm-rtems4.11
toolset is that it looks like I could have done this as well with the
arm-none-eabi toolset.  Since the main focus is to transition to the
RTEMS compiler, this probably doesn't matter anymore.


I am curious, were these the same set of steps that you had to take to
build Umon with the RTEMS toolset?




On Tue, Jun 23, 2015 at 12:23 PM, Jarielle Catbagan
<a class="moz-txt-link-rfc2396E" href="mailto:jcatbagan93@gmail.com"><jcatbagan93@gmail.com></a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">Hi Ed,

That is good news! I am currently setting up my development environment to
do the same as well.  Once I get that done I'll be inspecting the binaries
and testing it on my BBB.  I'll notify here how it goes.

On Jun 23, 2015 12:17 PM, "Ed Sutter" <a class="moz-txt-link-rfc2396E" href="mailto:ed.sutter@alcatel-lucent.com"><ed.sutter@alcatel-lucent.com></a> wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">
Jarielle,
Ok, I got the RTEMS based tools built on my machine here at work
and then rebuilt with the __ctype_ptr__ stuff removed and it builds
clean!  This is (hopefully) great news.
I can't test it till tonight (my beaglebone is at home); but my guess
is that the isspace() mystery is solved.
Ed
_______________________________________________
umon-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:umon-devel@rtems.org">umon-devel@rtems.org</a>
<a class="moz-txt-link-freetext" href="http://lists.rtems.org/mailman/listinfo/umon-devel">http://lists.rtems.org/mailman/listinfo/umon-devel</a>
</pre>
        </blockquote>
      </blockquote>
      <pre wrap="">_______________________________________________
umon-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:umon-devel@rtems.org">umon-devel@rtems.org</a>
<a class="moz-txt-link-freetext" href="http://lists.rtems.org/mailman/listinfo/umon-devel">http://lists.rtems.org/mailman/listinfo/umon-devel</a>

</pre>
    </blockquote>
    <br>
  </body>
</html>