Lesson 2: Setting up the toolchain

This article is for an old version of msp430-gcc and does not work with the latest version!

Find the updated lesson here.

In this lesson we will be setting up the msp430-gcc toolchain on our virtual machine. The timing for this couldn’t be better because just last month TI officially released msp430-gcc after taking it over from the open source community. This [hopefully] means there will be support for the latest chips as well as improvements and bug fixes. TI has actually provided a Linux installer, but I will show you how to compile it from source instead. I want to go through this exercise because the compiler for your target may not always be available in a pre-packaged binary or the version available may be older than required.

Step 1: Get the compiler sources and support files

If you remember from the last lesson, we already installed gcc in our virtual machine. However the version of gcc that is available in the repositories is built for your host architecture, in our case x86. Compiling code for a target that is a different architecture than your host machine is called cross-compiling. We will build a gcc (using gcc) which runs on an x86 machine, but compiles machine code for the msp430. So to start, fire up your virtual machine, open Firefox and go to TI’s download site.

At the bottom in the “Products Downloads” table, you should download these two files:

  • msp430-gcc-source.tar.bz2
  • msp430-support-files.zip

Open up a terminal, navigate to your downloads folder and extract the first package.

cd ~/Downloads
tar xvf  msp430-gcc-source.tar.bz2

This might take a while… If you are not familiar with the tar command, it is a very widely used archiving utility which supports multiple compression algorithms. The command line parameters we passed are as follows:

  • x – extract
  • v – verbose
  • f – for file, always followed by the filename of the file you want to compress/extract

If you want to learn more about the tar command you should read the man page (i.e. “man tar” in the command line).

Navigate to the newly created “sources/tools” directory. What you see in here may be a bit overwhelming, but really what TI has done is packaged all the components required to build the compiler and created a build system around it. Technically, gcc itself is only the compiler. The toolchain consists of many other packages which perform various tasks such as assembling, linking, built-in functions etc… Most of these are contained in binutils, but there are separate math libraries like mpc, mpfr and gmp. A standard C library (libc) is also typically included unless you are developing an operating system. In the case of TI’s package, newlib is the C library they have chosen to include but there are plenty others such as glibc and uClibc. We will go into more detail on some of these components in a later lesson. For now what you need to know is that typically you would compile binutils, gcc, and some version of libc separately using the following method:

  • configure, compile and install binutils
  • configure, partially compile and install gcc
    • partially compile means using make all-gcc and make install-gcc
  • configure, compile and install your standard c library
  • finish the installation by doing the full gcc compile
    • make all && make install

The reason you have do this sort of recursive dance with gcc is because the cross-compiler is required to build libc for your target architecture but gcc also references the standard C library when compiling application code, so it needs to be installed as part of the toolchain.

Step 2: Compile the toolchain

Compiling gcc takes long, so I let’s get it started and while it is compiling you can read the explanation for everything below.

cd ~/Downloads
sudo apt-get install texinfo expect libx11-dev g++ flex bison libncurses5-dev
mkdir build
cd build
export PREFIX=/opt/msp430-toolchain
export TARGET=msp430-none-elf
export PATH=$PREFIX/bin:$PATH
../sources/tools/configure --target=$TARGET --prefix=$PREFIX --program-prefix=msp430- --enable-languages=c --disable-nls
make all

Now that its running, here is the breakdown of what you just did.

sudo apt-get install texinfo expect libx11-dev g++ flex bison libncurses5-dev

Here we are installing packages that are required to compile gcc

  • texinfo: utility to help create documentation in various formats
  • expect: program which talks to other programs interactively, used in scripts
  • libx11-dev: X11 windowing system development package
  • g++: gnu C++ compiler (we only installed the C compiler last lesson)
  • flex: fast lexical analyser generator
  • bison: parser generator
  • libncurses5-dev:  screen handling and optimization package, basically a terminal upgrade
mkdir build
cd  build

Next we create a build directory. One very important note about compiling gcc is you cannot build it in the source directory. If you try, you are very likely to get build errors.

export PREFIX=/opt/msp430-toolchain
export TARGET=msp430-none-elf
export PATH=$PREFIX/bin:$PATH

Before building gcc, some environment variables should be set. We don’t want them to be system wide or persistent so we will set them only in the context of our shell. To do so we use the export command. The environment variables defined are:

  • PREFIX – the directory where your cross-compiler will be installed – I like to install my toolchains under the “/opt” directory
  • TARGET – the target architecture in the format <arch>-<target-os>-<abi/output> or something of that nature (its not really well defined). In our case the arch is msp430, target-os is none because it will be bare metal development, and output is elf format
  • PATH – the system path, already defined but we must add location of the binaries we will build to it
../sources/tools/configure --target=$TARGET --prefix=$PREFIX --program-prefix=msp430- --enable-languages=c --disable-nls

As with most gnu programs, the build environment is based on automake/autoconf. These tools can be fairly complicated to understand and the parameters that you have pass into them are sometimes obscure and poorly documented. Basically this is what need to be done:

  • Run the configure script passing in the required arguments which are defined by the configuration file for a specific program
  • The script analyses your system for various dependencies and from the information it collects, it is able to generate makefiles, configuration files and sometimes header files that will be compatible with your system. If you are not familiar with makefiles, don’t worry about it for now, I will have a lesson dedicated to them. Sometimes dependencies cannot be resolved in which case the configuration (or build) will fail
  • Compile the code
  • Install the program

In the case of gcc, the configure script accepts many arguments but only a few are required in most cases. The target and prefix argument are as described above in the environment variables section. The program-prefix simply adds a prefix to all the binary files, so for example gcc will become msp430-gcc. This is useful when you want to have one makefile that can build the same code for many architectures. For example, if I wanted compile main.c for both msp430 and arm, I could define my compiler as $(target)-gcc and then configure with target=msp430 to use msp430-gcc or configure with target=arm to use arm-gcc.

The disable-nls flag tells the build to disable Native Language Support (NLS) which basically means GCC only outputs diagnostics in English.

Finally, enable-languages tells the build system to compile only the specified languages. Only C is enabled since that is the language we will be using. If you are interested in the many other options for gcc compilation you can read all about them here.

One last thing, if you need to completely clean your build directory or rebuild from scratch,  the “make distclean” command is supposed to do this for you but in my experience it is often not effective. Its easier and safer to just delete the whole build directory and start again.

Did the compilation finish? If not take a coffee break…

Now that its done, you have to install it. Since /opt is owned by root, the install command has to be run with sudo.

sudo make install

This copies all the required files from the build directory to the directory specified by the environment variable PREFIX.

Step 3: Adding the support files

The final step before we are done is installing the device support header and linker files. These files are provided separately from TI in the second file downloaded in step 1.

cd ~/Downloads
unzip msp430-support-files.zip

The files will be extracted to an “include” directory. Inside you will see a lot of header files and linker scripts. The header files include all the device specific definitions and memory locations for registers and peripherals. The linker scripts tell the linker how to map various sections of code to physical memory locations on the device. Although they are all packaged together, the header and linker files belong in different locations in your installation. Use the following commands to copy the files to the appropriate location.

cd include
chmod -R 644 *
sudo cp *.ld $PREFIX/msp430-none-elf/lib/430/
sudo cp *.h $PREFIX/msp430-none-elf/include

The second command is used to change the permissions of the files so they can be read by any user. This way the user compiling does not have to have  root privileges. The location where the files are copied to is defined by the toolchain. If you put them somewhere else, it won’t find them.

And there you have it. Next lesson I will give you your first piece of code to compile, introduce you to the various utilities that come with the compiler and show you how to program and run the application on the MSP430 Launchpad.


  1. I followed all the instructions to the tee but when I type in:

    ./sources/tools/configure –target=$TARGET –prefix=”$PREFIX” –program-prefix=msp430- –enable-languages=c –disable-nls make all

    I get this error message:

    configure: WARNING: you should use –build, –host, –target
    configure: WARNING: you should use –build, –host, –target
    checking build system type… Invalid configuration ‘make’: machine ‘make’ not recognized
    configure: error:/bin/bash ./Downloads/sources/tools/config.sub make failed

    1. Hi Stephen,

      Its looks like the double dashes before each of the arguments got changed to single dashes. Can you confirm that you typed it in with double dashes. Also can you show me the output from each of the following commands:

      echo $TARGET
      echo $PREFIX

  2. Nice writeup; it’s really easy to follow!

    On my archlinux system, it runs well until it start compiling sources/tools/gas/as.c. I get an error saying this:

    ../../sources/tools/gas/as.c: In function ‘print_version_id’:
    ../../sources/tools/gas/as.c:224:14: error: ‘TARGET_ALIAS’ undeclared (first use in this function)
    ../../sources/tools/gas/as.c:224:14: note: each undeclared identifier is reported only once for each function it appears in
    ../../sources/tools/gas/as.c: In function ‘parse_args’:
    ../../sources/tools/gas/as.c:635:5: error: ‘TARGET_ALIAS’ undeclared (first use in this function)
    ../../sources/tools/gas/as.c:649:44: error: ‘TARGET_CANONICAL’ undeclared (first use in this function)
    fprintf (stderr, _(“canonical = %sn”), TARGET_CANONICAL);
    ../../sources/tools/gas/as.c:650:43: error: ‘TARGET_CPU’ undeclared (first use in this function)
    fprintf (stderr, _(“cpu-type = %sn”), TARGET_CPU);
    Makefile:894: recipe for target ‘as.o’ failed
    make[4]: *** [as.o] Error 1

    Any idea what’s causing this?

    1. Thanks David. I can’t say I have seen that error before, but it seems like there may be some incompatibility with autoconf. If you look in the build directory, you should see a file called config.status. Open it up and see what target-alias is set to. It should be set to the same value as the target argument, which is msp430-none-elf. Can you please verify that yours is set correctly? If so, the same file exists under the gas directory. Check that one as well.

  3. Hi, I tried to follow your instructions on my archlinux machine but I ran into an error while building the receipe for gdb. It said that the linker couldn’t find library expat which is for parsing XML files. So I checked my installed packages and found out that it’s installed. Therefore I created a dummy program to compile with that library. That worked out without any problems. Here’s the error:

    gcc -g -O2 -static-libstdc++ -static-libgcc
    -o gdb gdb.o msp430-tdep.o msp430-cio.o ser-base.o ser-unix.o ser-pipe.o ser-tcp.o remote.o dcache.o tracepoint.o ax-general.o ax-gdb.o remote-fileio.o remote-notif.o ctf.o remote-sim.o cli-dump.o cli-decode.o cli-script.o cli-cmds.o cli-setshow.o cli-logging.o cli-interp.o cli-utils.o mi-out.o mi-console.o mi-cmds.o mi-cmd-catch.o mi-cmd-env.o mi-cmd-var.o mi-cmd-break.o mi-cmd-stack.o mi-cmd-file.o mi-cmd-disas.o mi-symbol-cmds.o mi-cmd-target.o mi-cmd-info.o mi-interp.o mi-main.o mi-parse.o mi-getopt.o tui-command.o tui-data.o tui-disasm.o tui-file.o tui-hooks.o tui-interp.o tui-io.o tui-layout.o tui-out.o tui-regs.o tui-source.o tui-stack.o tui-win.o tui-windata.o tui-wingeneral.o tui-winsource.o tui.o python.o py-arch.o py-auto-load.o py-block.o py-bpevent.o py-breakpoint.o py-cmd.o py-continueevent.o py-event.o py-evtregistry.o py-evts.o py-exitedevent.o py-finishbreakpoint.o py-frame.o py-framefilter.o py-function.o py-gdb-readline.o py-inferior.o py-infthread.o py-lazy-string.o py-linetable.o py-newobjfileevent.o py-objfile.o py-param.o py-prettyprint.o py-progspace.o py-signalevent.o py-stopevent.o py-symbol.o py-symtab.o py-threadevent.o py-type.o py-utils.o py-value.o elfread.o stap-probe.o posix-hdep.o gdbtk.o gdbtk-bp.o gdbtk-cmds.o gdbtk-hooks.o gdbtk-interp.o gdbtk-register.o gdbtk-stack.o gdbtk-varobj.o gdbtk-wrapper.o c-exp.o cp-name-parser.o ada-exp.o jv-exp.o f-exp.o go-exp.o m2-exp.o p-exp.o version.o annotate.o addrmap.o auto-load.o auxv.o agent.o bfd-target.o blockframe.o breakpoint.o break-catch-sig.o break-catch-throw.o findvar.o regcache.o cleanups.o charset.o continuations.o corelow.o disasm.o dummy-frame.o dfp.o source.o value.o eval.o valops.o valarith.o valprint.o printcmd.o block.o symtab.o psymtab.o symfile.o symfile-debug.o symmisc.o linespec.o dictionary.o infcall.o infcmd.o infrun.o expprint.o environ.o stack.o thread.o exceptions.o filesystem.o filestuff.o inf-child.o interps.o minidebug.o main.o macrotab.o macrocmd.o macroexp.o macroscope.o mi-common.o event-loop.o event-top.o inf-loop.o completer.o gdbarch.o arch-utils.o gdbtypes.o gdb_bfd.o gdb_obstack.o osabi.o copying.o memattr.o mem-break.o target.o target-dcache.o parse.o language.o build-id.o buildsym.o findcmd.o std-regs.o signals.o exec.o reverse.o bcache.o objfiles.o observer.o minsyms.o maint.o demangle.o dbxread.o coffread.o coff-pe-read.o dwarf2read.o mipsread.o stabsread.o corefile.o dwarf2expr.o dwarf2loc.o dwarf2-frame.o dwarf2-frame-tailcall.o ada-lang.o c-lang.o d-lang.o f-lang.o objc-lang.o ada-tasks.o ada-varobj.o c-varobj.o ui-out.o cli-out.o varobj.o vec.o go-lang.o go-valprint.o go-typeprint.o jv-lang.o jv-valprint.o jv-typeprint.o jv-varobj.o m2-lang.o opencl-lang.o p-lang.o p-typeprint.o p-valprint.o sentinel-frame.o complaints.o typeprint.o ada-typeprint.o c-typeprint.o f-typeprint.o m2-typeprint.o ada-valprint.o c-valprint.o cp-valprint.o d-valprint.o f-valprint.o m2-valprint.o serial.o mdebugread.o top.o utils.o ui-file.o user-regs.o frame.o frame-unwind.o doublest.o frame-base.o inline-frame.o gnu-v2-abi.o gnu-v3-abi.o cp-abi.o cp-support.o cp-namespace.o reggroups.o regset.o trad-frame.o tramp-frame.o solib.o solib-target.o prologue-value.o memory-map.o memrange.o xml-support.o xml-syscall.o xml-utils.o target-descriptions.o target-memory.o xml-tdesc.o xml-builtin.o inferior.o osdata.o gdb_usleep.o record.o record-full.o gcore.o gdb_vecs.o jit.o progspace.o skip.o probe.o common-utils.o buffer.o ptid.o gdb-dlfcn.o common-agent.o format.o registry.o btrace.o record-btrace.o waitstatus.o inflow.o init.o
    ../sim/msp430/libsim.a ../readline/libreadline.a ../opcodes/libopcodes.a ../bfd/libbfd.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a ../libgui/src/libgui.a -L/home/dummy/MSP-GCC/build/tk/unix -ltk8.4 -L/home/dummy/MSP-GCC/build/tcl/unix -ltcl8.4 -lX11 -ldl -lieee -lm -ldl -lncurses -lz -lm -lpthread -ldl -lutil -lm -lpython3.4m -Xlinker -export-dynamic -Wl,-Bstatic -lexpat -Wl,-Bdynamic -llzma ../libiberty/libiberty.a build-gnulib/import/libgnu.a
    /usr/bin/ld: cannot find -lexpat
    collect2: error: ld returned 1 exit status
    Makefile:1236: recipe for target ‘gdb’ failed
    make[2]: *** [gdb] Error 1
    make[2]: Leaving directory ‘/home/dummy/MSP-GCC/build/gdb’
    Makefile:14093: recipe for target ‘all-gdb’ failed
    make[1]: *** [all-gdb] Error 2
    make[1]: Leaving directory ‘/home/dummy/MSP-GCC/build’
    Makefile:844: recipe for target ‘all’ failed
    make: *** [all] Error 2

    1. Hi Peter,

      When you say libexpat is installed, do you mean libexpat1? I believe in this case you would need the development package. Do you have libexpat1-dev installed? If not try installing that package as well. If the linker says it cannot find the library, make sure the location of the library is passed to the linker. Let me know if that helps.

  4. I have a few questions regarding link scripts in general. In a typical project, are these files manually modified? If so, what reasons would one have for adapting them? Are the text files usually directly modified or are they generated by some kind of configuration editors?

    1. Linker scripts are typically written for a specific device because they tell the linker where to place code in memory. Since most devices (at least at the microcontroller level) have static memory maps, these locations will not change. Therefore it is not often that linker scripts are modified. However, there are cases where it may be desired. For example, a specific region of program flash could be allocated for a dedicated purpose, such as storing version information. Or maybe the developer wants to set the stack in a specific location different from the default. U-boot uses the linker script to allocate all command line calls to one section of code, amongst other things. Linker scripts will also change if the code is being run bare metal vs in an OS environment. In some cases, the desired changes can simply be passed to the linker as command line arguments rather than modifying the linker script.

      Linker scripts are usually modified manually, for gcc anyways. I am not aware of any tool that does this for you. Some IDEs do however. For example. IAR Workbench provides the option to change some parameters of the linker script through the IDE. I am not sure if it does any sanity checking though. Either way, modifying the linker script requires a solid knowledge of the architecture and device. I will briefly cover linker scripts in lesson 5 to explain how it relates to the architecture and memory map of the MSP430.

  5. I loaded this up on a Debian 7.6 machine with NO X and it worked with no problems. Thanks for the excellent tutorials Chris!!!

  6. Thanks for the clear tutorial, it worked on Ubuntu 14.04 flawlessly. I’d like to ask some help to create a simple Makefile or any example how to create one for this toolchain.

    1. Hi Greg. Glad to hear that it worked on your system. I will be covering makefiles in a few tutorials, but if your in a crunch for time and need some help sooner, I can get you started on the side. I’ll touch base with you by email and we can discuss further.

      1. It took 6.5 hours to compile on my slightly overclocked (@ 800 Mhz) raspberry pi!! I haven’t tested the toolchain yet. I will compile and download the blink example to my launcpad equipped with msp430g2553 asap.

    1. Nice! Thanks for the update. That’s a great idea. Once day I hope to be able to allow users to upload their projects to share here, but until then I’ll point those interested in your direction!

  7. I have been implementing your Tutorial to install and setup VirtualBox with Lubuntu and MSP430-gcc on my Windows 8.1 computer. Everything has gone OK up to step 3 of Lesson 2. The only small query up to this point was a slight difference in one of the files downloaded from TI from msp430-support-files.zip to msp430-gcc-support-files.zip.

    I have a query in step 3 of Lesson 2. I implemented cd ~/Downloads and unzip msp430-gcc-support-files.zip. The next step in your lesson is cd include, however there is no include directory in Downloads. Under Downloads there is a build and a sources directory, and under sources a tools directory, and under tools an include directory. So I changed to the peter@peter-VirtualBox:~/Downloads/sources/tools/include directory to implement chmod -R 755 *. However when I implement the command sudo cp *.ld $PREFIX/msp430-none-elf/lib/430/ I get the error message cp: cannot stat ‘*.ld’: No such file or directory. Have you any suggestions?

    1. Hi Peter,

      Looks like TI has been busy at work. They are already at version 3.2 and when I started this in September they were at version 2.0. Looks like they changed a few things so I may have to make updates to the tutorial. It looks like they got rid of the include directory in msp430-gcc-support-files.zip so I think you would just want this:

      cd ~/Downloads
      unzip msp430-gcc-support-files.zip
      cd msp430-gcc-support-files
      sudo cp *.ld $PREFIX/msp430-none-elf/lib/430/

      I think it should work for you. I hope that’s the only thing they changed. Let me know.

      1. I did exactly as you suggested but after the sudo … line it returned the error message cp: target ‘/msp430-none-elf/lib/430/’ is not a directory. However it is actually a directory under /opt/msp430-toolchain which I think is what PREFIX means. Is there a way I can test PREFIX?

        1. To print out any environment variable in Linux you can use the echo command. For example:

          echo $PREFIX

          To print all the environment variables use the command ‘printenv’. Using export to define an environment variable is only temporary to that specific shell context so maybe you lost it and need to set it again.

  8. Oops! I have since realized the PREFIX assignment was not persistent so I reassigned it with export PREFIX=/opt/msp430-toolchain. I was then able to successfully implement sudo cp *.ld $PREFIX/msp430-none-elf/430/. I did not repeat chmod _R 755 * before doing the lines you suggested. Should I have?
    I have proceeded on to Lesson 3 and all is OK until step 4 where the git clone command failed saying you must specify a repository for clone. Any suggestions?

    1. Using chmod will change the permission of the files and should be persistant so if you did that once you should be OK.

      For the issue with git clone, Im out of town now so I can’t retest but if you could copy the command and error maybe I can help. Otherwise Ill get back to you on this when I get home in January.

  9. I downloaded msp430-gcc-support-files.zip from the TI website which looks like it might be an updated version of the support files. I just read Peter’s comments and have tried

    cd msp430-gcc-support-files
    sudo cp *.ld $PREFIX/msp430-none-elf/lib/430/

    but it doesn’t look like there is a folder named ‘lib’ when I look in msp430-none-elf. is there something I’m missing somewhere?

    1. Hi Dan,

      I actually haven’t got around to compiling the latest version of gcc, its something I need to do and then update the post. It seems strange that there is no ‘lib’ folder in there. What folders/file do you have in msp430-none-elf?

      1. I actually have a similar issue to Dan but in my /opt/msp430-toolchain folder I have nothing inside that at all.
        No msp430-none-elf

        Which command is meant to create msp430-none-elf

        1. make install is supposed to create the directory. Can you print out the environment variable PREFIX from the console you are compiling from?
          i.e. echo $PREFIX

          1. xxxx@xxx-VirtualBox:~/Downloads/build$ echo $PREFIX
            xxx@xxx-VirtualBox:~/Downloads/build$ echo $TARGET
            xxx@xxx-VirtualBox:~/Downloads/build$ echo $PATH

            When I run the sudo make install command, I get this

            xxx@xxx-VirtualBox:~/Downloads/build$ sudo make install
            make[1]: Entering directory ‘/home/damola/Downloads/build’
            /bin/bash ../sources/tools/mkinstalldirs /opt/msp430-toolchain /opt/msp430-toolchain
            make[2]: Entering directory ‘/home/damola/Downloads/build/bfd’
            make[2]: *** No rule to make target ‘install’. Stop.
            make[2]: Leaving directory ‘/home/damola/Downloads/build/bfd’
            Makefile:2721: recipe for target ‘install-bfd’ failed
            make[1]: *** [install-bfd] Error 2
            make[1]: Leaving directory ‘/home/damola/Downloads/build’
            Makefile:2178: recipe for target ‘install’ failed
            make: *** [install] Error 2

          2. Ok that all looks good except for the make install part. Are you sure that when you ran the configure script that the PREFIX was passed in correctly. There was a syntax error initially which caused the prefix to be set incorrectly. Even if you set the prefix again properly before make install, it will still not work. I ran into this problem myself. I would create a new build directory (build-2 maybe) and try the whole procedure again. I am doing it myself and once it is done I will let you what happens.

          3. There doesn’t seem to be a reply button to your last reply.

            Anyway, I created a build_2 folder and ran the configuration script again.
            ../sources/tools/configure –target=$TARGET –prefix=$PREFIX –program-prefix=msp430- –enable-languages=c –disable-nls

            Then after that I run the
            make all command?
            then the sudo make install?

            I get the same errors as before.

          4. Hmm, that should have worked. I ran through the whole process again last night and it finished no problem. Are you running the same version of Lubuntu and have all the packages installed? Can you check that ‘make all’ finished successfully? Try using ‘make all 1>/dev/null’ when you compile to see only the errors. Maybe the compilation didn’t complete correctly for some reason. Also could you send me the output from the configure script by email (info@simplyembedded.org). I’ll compare it to mine to make sure have the same setup.

      1. Looks like I had a typo in the command when I migrated the site. The environment variable PREFIX was not being set correctly. Delete everything inside the build directory and run the whole configuration again with the command above which I have fixed. Let me know if that solves the issue.

  10. I just tried redoing the whole build with the updated syntax and it looks like it worked…next issue I’m having is a directory named “include” isn’t created when I unzip the msp430-gcc-support-files

    Is there a command that’s supposed to make it?


    1. Hi Dan,

      The directory should already by included as part of the build i.e. once you run ‘sudo make install’. Do you have the rest of the /opt/msp430-toolchain directory? It should just be a straight copy from the unzipped support files to the include directory. There should be other header files in there already from the build.

      1. Looks like there is an include directory but it’s under sources/tools/

        I ran this instead from your reply to Peter earlier.

        unzip msp430-gcc-support-files.zip
        cd msp430-gcc-support-files
        sudo cp *.ld $PREFIX/msp430-none-elf/lib/430/

        I think that seems to have worked

        1. The /opt directory is in the root directory. You don’t want to install the toolchain to the sources directory. The intermediate files will go there, but once you do the make install step, all the required files will be copied over. In a console type:

          cd /opt/msp430-toolchain

          You should see a few directories in there, one of them being msp430-none-elf, another bin etc…

  11. I get this error at the beginning of make install:

    mkdir -p — /build/msp430-toolchain /build/msp430-toolchain
    /bin/sh: line 3: cd: ./bfd: No such file or directory
    make[1]: *** [install-bfd] Error 1
    make[1]: Leaving directory `/nobackup2/msp430-gcc/build’
    make: *** [install] Error 2

    Not sure what to do here.

  12. Worked perfectly on lubuntu 15.04 32-bit in Virtualbox on Windows 7 64-bit host. Thanks for great getting-started introduction. I have liked lessons 1-10 a lot.

  13. Just an update regarding file name changes on the TI source and support files, as of October 26, 2015, the zip of support files is named msp430-gcc-support-files.zip, which unzips to a folder msp430-gcc-support-files (not “include”). All else as advertised. Thanks for an excellent view of the details under the hood!

      1. Hello,
        Is there any downfall to using the TI GCC full installer? I am running Ubuntu and after many errors/dependency issues I just used the installer.
        I would really love to follow this guide, but I am curious what else might be out of date now?

        1. Hi Jessie,

          No there is no downside to using the TI installer. I just wanted to demonstrate how to compile a cross-compiler. It is hard to keep with the latest version when your compiling it on your own because of all those dependencies. So go ahead and use the latest installer. The makefile may need to be tweaked to account for files moving around – specifically the includes and linker scripts. But that would happen regardless. Hopefully none of the header files themselves have changed (I am not at the latest version yet myself).

  14. Looks like this tutorial hasn’t been touched in a while, but it looks like between April 2015 and July 2016, maintenance of the msp430-gcc source code changed hands from Red Hat to Somnium who changed the directory structure of the archive. A lot. I couldn’t figure out the correlation between sources/tools and what’s there now. Any chance you’d be willing to update the guide?

    1. Hi Alvaro. Yeah, I will definitely look into upgrading the post. I haven’t used the latest version of the compiler myself so thanks for bringing up the differences.

  15. Hi,
    I am stuck at this error after make all step

    collect2: error: ld returned 1 exit status
    ../../sources/tools/gcc/c/Make-lang.in:71: recipe for target ‘cc1’ failed
    make[2]: *** [cc1] Error 1
    make[2]: Leaving directory ‘/home/dummy/Downloads/build/gcc’
    Makefile:6388: recipe for target ‘all-gcc’ failed
    make[1]: *** [all-gcc] Error 2
    make[1]: Leaving directory ‘/home/dummy/Downloads/build’
    Makefile:858: recipe for target ‘all’ failed
    make: *** [all] Error 2

    1. Hi Harper. This might be because you are using the latest version of the compiler, and the steps in this tutorial don’t yet reflect those updates. You either download an older version of the compiler source, or you can use the installer until I update this tutorial.

Leave a Reply

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