chipKIT® Development Platform

Inspired by Arduino™

Building chipKIT compiler on Ubuntu 14.04 64-bit

Created Tue, 29 Mar 2016 15:40:16 +0000 by jdeguire


Tue, 29 Mar 2016 15:40:16 +0000

Apologies if this is the wrong section, but this appears to be the one most related to building source stuff.

Anyway, I've been on a quest to build the chipKIT compiler from [url][/url] using the script from [url][/url]. I'm doing this on Ubuntu 14.04 LTS 64-bit (in VirtualBox). The README that is provided with the script states that it was meant for OS X 10.6 or 10.7, however.

Unfortunately, I am running into a bit of trouble at the moment. On the plus side that gives me an opportunity to at least share what I've done so far in case anyone else wants to try building on Ubuntu. :)

Prerequisites The README provides the software packages needed for OS X, but things are a bit different here. Here are the packages you need; get them either using the apt-get install command or via the Ubuntu Software Center. Remember that these are for Ubuntu 14.04 64-bit.

  • build-essential
  • mingw32
  • gcc-multilib
  • g++-multilib
  • texinfo
  • flex
  • bison
  • libncurses5
  • libncurses5-dev
  • gcc-arm-linux-gnueabi
  • g++-arm-linux-gnueabi

Edit: Added g++-multilib package. Edit 2016 Mar 31: Added ARM cross-compiler packages.

The other packages listed (curl, rsync, etc.) should already be installed. The "growl" and "growl-notify" packages are not needed as they are specific to OS X. You'll still get nice notifications in Ubuntu.

NOTE: The "build-essential" package will bring in GCC 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.1). This is different from what the script's README wanted (GCC 4.2), but ought to be OK since the newest chipKIT compiler is based on GCC 4.8.3.

You also need Texinfo, but the version that the Ubuntu package repository provides is too new and will cause all sorts of errors with GCC 4.8 docs. You can tell GCC to not build its docs, but unfortunately the script barfs on the warnings the GCC instead outputs. Instead, you need to build and install an older Texinfo from source using the instructions provided at [url][/url].

Script Modifications I grabbed the latest script from GitHub and made a few mods to make it run. I have attached the modified script to this message.

**1.**The first modification is minor. Search for the comment "#Process the arguments" to see a case structure to handle command-line options. You'll see a reference to a function (or whatever they call those in Bash-speak) called "show_usage". However, that function is defined after it is referenced and so will not work. Find the "show_usage()" function and move it above the case structure.

**2.**To make the other change, search for the comment "#Check out the source code". Scroll down a bit and you'll notice that the portion of the script to grab the source of the actual compiler is commented out! Uncomment that section and then change the GIT_CHIPKIT_CXX_REPO variable to [url][/url].

Edit 2016 Mar 31: Added new mods to script

**3.**The script needs to be modified if you are running on a 64-bit Linux to force the chipKIT compiler to be built in 32-bit mode. Search for "xDarwin-image" to find an if-statement. This checks if the script is running on OS X. Scroll down a bit to find the corresponding else-clause and add the following inside of it:

# We need to force a 32-bit build if we're on 64-bit Linux
    if [ `getconf LONG_BIT` = "64" ]
        if [ "x$SKIPNATIVE" == "x" ] ; then
            COMPATIBILITY_FLAGS="-m32 -march=i686"
            export CXX_FOR_BUILD="g++ $COMPATIBILITY_FLAGS"
            export CC_FOR_BUILD="gcc $COMPATIBILITY_FLAGS"
            export CC="gcc $COMPATIBILITY_FLAGS"
            export CPP="cpp $COMPATIBILITY_FLAGS"
            export CXX="g++ $COMPATIBILITY_FLAGS"
            export LD="gcc $COMPATIBILITY_FLAGS"
            export AR="ar"
        fi  # SKIPNATIVE

You could probably change the "i386" in there to something more modern if you're just building for yourself.

**4.**Ubuntu 14.04 has a different name for the ARM cross-compiler than OS X does, it seems, so the script needs to be updated to figure out which compiler prefix (the "blahblah" in "blahblah-gcc"). Search for "unset ARMLINUX32_HOST_PREFIX" near the top of the script. Replace that line and the following assignment with the following code:

# Figure out which ARM cross compiler we have. Candidates are:
# arm-linux-gnueabi-gcc           (Ubuntu)
# arm-none-linux-gnueabi-gcc      (OS X)
if [ "x$ARMLINUX32_HOST_PREFIX" == "x" ]; then
 WHICH_ARM_GCC=`which arm-none-linux-gnueabi-gcc`
 if [ "x$WHICH_ARM_GCC" != "x" ] ; then

Running the Script At this point you should be able to run the script. If you've already run the script once and thus have already checked out the code, you can pass the "-N" command-line option to stop the script from re-downloading the source. In the future, I may try adding an option to only download the sources for archival purposes.

...Aaannnnd I'm Stuck Edit 2016 Mar 31: This is no longer true! I am no longer stuck! :D So it is at this point I am stuck in the build. What appears to be happening is that the chipKIT build (pic32-gcc) is segfauting while trying to build Newlib. I'm not sure why this is happening, but I wonder if it is because I am building on a 64-bit OS and thus building a 64-bit version of the compiler. I notice that the script appears to force a 32-bit build when on OS X, so hopefully I can leverage that code to make it work. I'll update this thread with my progress, but I'll attach my build log in case one of you guys has run into this before.

On another note, is is normal for the build to emit so many warnings? Ubuntu's GCC (4.8.4) seems to emit a whole lot of warnings when building the chipKIT compiler, mainly about local variables shadowing global ones of the same name.

Edit 2016 Mar 31: This post used to have a modified build script and a log showing where I was originally stuck building. I have removed both of those. A later post has a new build script that you should use instead.


Tue, 29 Mar 2016 17:05:41 +0000

I think building on 64-bit will be doomed to failure even if you get it to complete.

I have requested a 64-bit version of the compiler from the maintainers, but they claim that it would mean making changes to the internals to get it to work on 64-bit.

Out of interest, why exactly are you attempting to compile it yourself when there are binaries available?


Wed, 30 Mar 2016 12:08:00 +0000

Hi majenko,

The pre-built distributions appear to not come with the GNU C++ libraries, which would be nice to have. That, and it is a good excuse for me to get back into Linux and re-learn all that I've forgotten long ago! :mrgreen:

You are right that the 64-bit build was the issue. I was able to modify the script to force a 32-bit build and it got much further along. Right now, it is failing to build the ARM->MIPS Canadian cross compiler, which I assume is for the chipKIT Pi stuff. I didn't install any ARM tools, so I wouldn't expect it to build just yet. I don't need the ARM compiler at all, but I'll get it building and update this thread so that others who need it can use it.

I'll clean up my modified script a bit and post the updated version when I get a bit further along.


Thu, 31 Mar 2016 13:47:21 +0000


I was able to build everything, including the ARM->MIPS compiler, on Ubuntu 14.04. Attached to this post is the updated script needed to do that. I'll edit the first post with the extra prerequisites needed for it as well as the additional modifications to the script I need.

Now to see if I can build it with full libstdc++ support! Hopefully, simply changing SUPPORT_HOSTED_LIBSTDCXX at the very top of the file to an empty string ("") will do it.


Thu, 31 Mar 2016 15:07:27 +0000

That's great work! If you should get it working with the gcc c++ library I may have to think about providing it as an optional alternative to the stock compiler on UECIDE...

Sent from my SM-T555 using Tapatalk


Thu, 31 Mar 2016 16:00:27 +0000

Another script update:

This version adds the "-S" option, which will allow you to download the source code without building it. This can be used if you want to keep a local archive of the code. Do not use this with the "-N" option, which will try to build without downloading the source.


Fri, 01 Apr 2016 18:49:59 +0000

That's great work! If you should get it working with the gcc c++ library I may have to think about providing it as an optional alternative to the stock compiler on UECIDE...

At the top of the script, change the variable SUPPORT_HOSTED_LIBSTDCXX to an empty string (""). Then, in NEWLIB_CONFIGURE_FLAGS and GCC_CONFIGURE_FLAGS right below that, remove the "--disable-hosted-libstdcxx" option. That appears to cause the script to build the full C++ library.

Note that I haven't yet used the compiler to make sure it actually works; I'm still working through building it.

Also, search for "-march=i386" and change that to "-march=i686".


Tue, 05 Apr 2016 15:20:15 +0000

Attached is yet another script update!

This update is fairly substantial, so instead of posting all of the details of what I did I'll just describe the new features. You can use a diff tool such as Beyond Compare, WinMerge, or Meld (Ubuntu) to see what I've changed.

  • Add "-A" option to disable building of the ARM->MIPS cross-compiler.
  • Add "-G" option to enable building of the Graphite loop optimization framework. This enables certain optimizations in GCC that can re-arrange loops and auto-parallelize them. This may be of limited use on the PIC32, but the option is there for anyone who wants it.
  • Add "-X" option to enable building the full libstdc++ library to get full C++ support. Note that this has not yet been tested and so further modifications may be needed to make C++ actually work.
  • In order for GCC to properly build Graphite, I had to update the script to download and build a stand-alone version of the ISL library. The download comes from the GNU FTP server. The CLooG library comes with a version of ISL, but a bug prevents GCC from accepting it as a usable version. NOTE: If you want the sources only, use the "-G" and "-S" options together.
  • For 64-bit Linux, change the build architecture from "i386" to "i686".
  • The sources contain PIC32 device info files that need to be included with the compiler images when they are built; however, the pic32-part-support Makefile did not provide a means to add them. The script will add a build target to "pic32-part-support/Makefile" called "install-devinfo" that will install the device info files to the proper places (I copied the XC32 layout for this) and then make that target when installing the headers.
  • Update USE_PPL and USE_CLOOG variables as needed when building those libraries for each architecture (native, Linux32, Win32, ARM-Linux).
  • Minor updates to echoed output that better points out which architecture is currently being worked on.


Tue, 05 Apr 2016 18:09:12 +0000

With previous mods of the script, I was pulling the toolchain source from [url][/url] as I thought that was the "proper" location. It does appear that future builds will come from there, but the current binary release provided with the latest chipKIT Core is built from the "dev_src48x" branch at [url][/url].

This version of the script is exactly the same as the previous except that it reverts back to the original script's behavior of pulling the toolchain source from the "mariusgeanta" fork. This will allow the build to more closely match the binary release. To switch between branches, simply uncomment one of the following lines in the script and comment out the other:



Wed, 11 May 2016 22:31:37 +0000

One more update. Like previous scripts, the toolchains built from this haven't yet gotten much runtime so keep in mind that you use these at your own risk.

Since last time, I've also learned that you must explicitly pass "-lstdc++" when linking if you want to use stuff from the C++ library (assuming you enabled it). If you're getting linker errors about undefined references to C++ symbols, give that a shot.

  • Attempted to clean up the indentation and many of the commands the script issues to make it easier to modify in the future. Many of the commands redefined variables like "CFLAGS_FOR_TARGET", "CXXFLAGS_FOR_TARGET", and so on, but redefined them using the same values over and over again. Where possible, commands now reference common variables at the top of the file such that changing those common variables should apply the changes to all relevant commands, thus helping to ensure all versions of the toolchain are built with the same options.
  • Add -E option to disable the SJLJ exception handling model, which should use the DWARF2 exception handling model instead. I have not yet tried out this option, so DWARF2 exceptions could be horribly broken for all I know.
  • Remove configuration options that disabled C++ exceptions and RTTI, so those should now be usable when building C++ code.
  • Remove all uses of the PPL library as GCC 4.8 no longer requires it. This matters only if you are building in Graphite optimizations.
  • Copy library and processor-specfic file sources from the pic32-part-support/ directory into each install image as it can come in handy. This can be disabled to give you a smaller install image by opening the script and setting SKIPLIBSOURCES to "yes".

If you find an issue, consider attempting a fix and uploading your successes here. That'll help others who may find it useful.


Fri, 13 May 2016 18:27:56 +0000

  • Fix an issue which may prevent device info files from being copied to the right places.
  • If building with DWARF2 exceptions, patch the file "gcc/libgcc/" to provide the pic32mx target with the proper MIPS exception unwind implementation. A backup of the file is made when this is done.


Thu, 04 Aug 2016 17:07:16 +0000

In order to use C++ exceptions, you'll have to use a custom linker script with your project. The default linker scripts inadvertently throw away some exception handling info needed during the stack unwind sequence.

  1. Go to <chipKIT_install_dir>/pic32mx/lib/proc/<your_processor> and copy the <your_processor>.ld file into your project.

  2. Open up your new script and look for the ".data" section. It will look like this:

.data   :
    *( .gnu.linkonce.d.*)            &lt;----- REMOVE ME!
    . = ALIGN(4) ;
  } &gt;kseg1_data_mem
  1. Remove the indicated line shown above. This section contains some info used by GCC's exception handling routines and having it here appears to cause the Microchip-specific linker extensions to not include this section in the data initialization tables. These tables are used to initialize static data and so not having the exception handling pieces in there causes very odd and hard to track problems (guess how I know...).

  2. Build with your new linker script by adding the following to your link step: