This is an adventure! I kept all of my stupid failures in here in case someone else is also lazy and stupid. Behold, the Internet age! As of this writing the Ada toolchain is not easy to use, so I think we need this sort of documentation. For reference this was done on Ubuntu 14.04 LTS x64.
A post on reddit regarding the aerospace industry’s use of Ada got me interested in the language. I’ve programmed enough in C to know the dangers inherent in the freedom it gives you, and I still have a lot to learn about “undefined behaviour”. I like that Ada is a trusted language for embedded environments, so I thought I’d try it out on my Arduino (ATMEGA-328P).
The toolchain isn’t available in the base apt repositories, unfortunately. There are two posts online that I found that both recommend building it yourself to ensure you have the latest patches and detail how to do it.
There’s this post by Tero Koskinen at the ada-language.com site which seems to be the primary reference for building a toolchain for Ada programming on AVR platforms. Tero’s post is a couple years out of date now though, so I’ll be building against the latest versions of everything involved.
Another post is this one by rolf_ebert on the AVR-ada sourceforge site. That post specifically targets Debian-based environments, which is useful for me. Again, it is quite out of date.
The version of gcc used in the second link is 4.7.0, whereas the latest available stable release is 4.9.1. The changelog is available here, and you can see that one change is that it defaults to Ada 2012 instead of 2005. The 4.8 changelog doesn’t reference Ada at all, and the 4.7 changelog mentions that a change was made that reduces debugger overhead and slightly reduces compilation time, by default. It looks like not much has changed, really. Regardless, I proceed in my blind march for progress!
I followed the build procedure for GCC to the letter for the second link, including the “export CC=gnatgcc” line at the top which is required to run the configure script.
The installation phase is where things went wrong. I thought I was a brilliant mastermind of the all-science and decided that the decimal at the beginning of the commands executing the native_build_env.sh and cross_build_env.sh were superfluous. They are not. Executing them directly does nothing, you have to “source” them. Presumably the decimal is an alias for source. I tested it separately and learned that it was true, yay learning.
I renamed the directory from /opt/gnat-4.7 to /opt/gnat-4.9, should have done that in the environment setup scripts. Following along with the second link, I replaced all references to 4.7 to 4.9. I also changed any references to i386-linux-gnu to my architecture of x86_64-linux-gnu, as reported by “dpkg-architecture -qDEB_HOST_MULTIARCH”.
I had to eventually edit the environment building files to reflect my new directory, I should have done it before my first make install.
In my blind march for progress I downloaded the latest available binutils, but the latest patches from the avr-ada-code project are for 2.20.1. This is the point where I realized I had the same problem with gcc. I applied the 4.7.2 patches successfully on gcc 4.9.1 with no errors, but I am a little concerned at this point that I’m missing something. The binutils patches failed, and so I reverted to the latest version that had the patches, 2.20.1.
I’ve had to fix patch files in the past before, but I decided against trying for this, as compilers and toolchains are basically magic to me still and I don’t want to introduce bugs.
I had these fun binutil make errors greet me halfway through the process:
../../../binutils-2.20.1/bfd/doc/bfd.texinfo:326: unknown command `colophon' ../../../binutils-2.20.1/bfd/doc/bfd.texinfo:337: unknown command `cygnus' make: *** [bfd.info] Error 1
Here’s a thread that seems relevant, but its about a more recent version. I just went into the relevant file and added an extra @ sign next to @colophon and @cygnus (@@colophon, @@cygnus) as I saw in the patch. This IRC conversation seems to indicate that this is an issue with texinfo 5 incompatibility with texinfo 4 targets, yay.
I downgraded to texinfo 4 by blindly accepting the advice of this Github issue post. A little apt-get remove texinfo here and a little dpkg -i there and I was done that bit. I ran “make install” again and it proceeded successfully. Awesome! In hindsight, my editing of the previous error was unnecessary. What I really needed to do was downgrade texinfo.
I had a build error when making gcc on file gcc-4.9.1/gcc/ada/switch-c.adb. The case/switch structure seemed to duplicate the ‘t’ switch, so I commented out the second one because it was shorter. Clearly, I am on a path of great success here. It compiled fine after that, but maybe I’m missing a command line argument. Whatever!
The next step for me was avr-libc, which has a slightly newer version available, 1.8.1 versus 1.8.0. Onward to progress!
On my first attempt I neglected to unset CC, CXX, and CPP. This gave me an error: “Wrong C compiler found; check the PATH!”. After actually following the instructions, it was smooth sailing for avr-libc.
For the Ada toolchain AVR-Ada I did not have gprbuild installed natively which is required. I apt-get install’ed gprbuild, and encountered a few errors on build:
After updating my path (which the instructions mention but I I didn’t understand until now) with export PATH=$PATH:/opt/gnat-4.9/bin it compiled without error. “make install” didn’t work after that, but that’s because I was supposed to “make install_libs”. All built, all installed! Woot! I don’t seem to have any examples to try and build yet, but this post is long enough anyway!
Sadly, the ultimate result is that code does not compile. Instead, I am greeted with the following:
gt; make avr-gnatmake -aL/opt/avrada/avr/lib/gnat/avr_lib/atmega328p/lib -XMCU=atmega328p -p -Pblink.gpr -XAVRADA_MAIN=blink_rel avr-gnatmake: cannot find RTS rts/avr5 make: *** [blink_rel.elf] Error 4
All that work and we still don’t have a working Ada toolchain. I found this post on the avr-ada-devel mailing list by Rolf Ebert who wrote the main document I’ve been following, it seems he’s found the same problem.
Need help with something or have a comment? Reach out!