bbb update..

Jarielle Catbagan jcatbagan93 at gmail.com
Wed Jun 24 01:42:29 UTC 2015


Yes, I also changed the library path in the makefile as well.

On Tue, Jun 23, 2015 at 6:32 PM, Ed Sutter <edsutterjr at gmail.com> wrote:
> Jarielle,
> Unfortunately my home linux machine seems to be *really* taking along time
> to build
> the tools.  I agree that the steps you took, while they may have worked,
> have other
> negative implications.  I didn't have to go through the same steps you did.
> I don't recall any error with __ctype_ptr__.
>
> Did you also change set the library path in the makefile?...
>
> # Using RTEMS Source Builder tools:
> ABIDIR          = $(HOME)/development/rtems/4.11/lib/gcc/arm-rtems4.11/4.9.2
> LIBABIDIR       = -L $(ABIDIR)
> TOOL_PREFIX     = arm-rtems4.11
>
> If my tools build ever completes I'll verify what I did earlier today...
> Ed
>
> 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
> <jcatbagan93 at gmail.com> wrote:
>
> 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" <ed.sutter at alcatel-lucent.com> wrote:
>
> 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
> umon-devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/umon-devel
>
> _______________________________________________
> umon-devel mailing list
> umon-devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/umon-devel
>
>
>
> _______________________________________________
> umon-devel mailing list
> umon-devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/umon-devel


More information about the umon-devel mailing list