– I never got this working fully but maybe there are some bits here you can use –

The story

I got a BBB and started with Derek Malloy’s awesome tutorial so I could finally put my awesome blinkery to work as an enormous wall-mounted, internet-synchronized clock.

Adafruit decided after customer feedback that it would ship the BBB with Debian installed. This is all fine and good (I actually have no idea) but the version of Debian that it runs requires that projects be compiled with hardware FPU (Floating Point Unit) support. When I compiled my program and executed it on the BBB I got an error:

http://stackoverflow.com/questions/11471722/libstdc-so-6-cannot-open-shared-object-file-no-such-file-or-directory

If you download a popular ARM-linux toolchain like Carlson-Minot’s arm-none-gnueabi, your program will build beautifully but not run at all on a BBB running Debian. It’s not Carlson-Minot’s fault, it’s that the BBB build of Debian requires a hardware FPU enabled toolchain.

If you use a Linux or Windows environment to create your BBB programs using the arm-none-gnueabihf toolchain, then everything’s hunky-dory. If you use OSX however, things are not so easy.

I found an arm-none-gnueabihf toolchain built for use on OSX here:

http://will-tm.com/cross-compiling-mac-os-x-mavericks/

When I dragged the toolchain over to my local disk, the copy routine decided to quit when it ran into a file that had a matching version expressed in CAPITAL LETTERS because I have a case-insensitive filesystem on my Macbook. To get around this (ignoring errors during the copy) I used Ditto from the terminal:

https://discussions.apple.com/thread/1462340?tstart=0

NOTE: With the above I think it skipped “xt_connmark.h”. It looks to have content to it so I copied that over manually. The version of the same file expressed in capital letters did not seem to have any useful content.

If Eclipse shows nasty icons where C++ library calls are present, even though the project builds/runs successfully:

https://stackoverflow.com/questions/10803685/eclipse-cdt-symbol-cout-could-not-be-resolved?answertab=votes#tab-top

If Eclipse cant’ find GDB, you’re probably using the GDB built for the host system (x86). You need to point Eclipse to the GDB that comes with the target toolchain. In my case:

/usr/local/willtm/bin/arm-willtm-linux-gnueabi-gdb

You also must select the shared library for the target under “Shared Libraries” in Eclipse debugging settings. In my case:

/usr/local/willtm/arm-willtm-linux-gnueabi/sysroot/lib

Otherwise you’ll get some crap:

http://stackoverflow.com/questions/13678923/eclipse-failed-to-execute-mi-command

Other maybe useful info

Building an arm-none-gnueabihf toolchain for OSX:

http://www.benmont.com/tech/crosscompiler.html

A more detailed account of building an OSX toolchain:

http://tblog.rool.at/?p=57

Will™’s cross-tool ng configuration:

https://gist.github.com/Will-tm/8f31886c7c25a1aba7b0

http://derekmolloy.ie/beaglebone/setting-up-eclipse-on-the-beaglebone-for-c-development/

Linaro, a company that hosts lots of toolchain builds for different OSes. I asked them to provide an OSX build, we’ll see how they respond!:

http://www.linaro.org/downloads/

Lots of BBB Debian info:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.