I’m sure that this is a case of pilot error, but… I’ve just, like 20 minutes ago, installed the local toolchain to run on my Mint 17 desktop. I’ve followed the instructions on the spark/core-firmware page on GitHub. I go into the core-firmware/build directory and invoke make. When it attempts to compile the first file, it complains about stdlib.h not being available.
If I do a find at the top of the Spark directory (two levels up from build), I don’t see stdlib.h. I’m assuming that the stdlib.h file is meant to be pulled from the toolchain include path. But, looking at the output of the make command, I don’t see an entry in the include path that is outside of the spark tree.
johnbo@k100rs ~/Projects/Spark/core-firmware/build $ make
Building core-common-lib
Building file: ../CC3000_Host_Driver/cc3000_common.c
Invoking: ARM GCC C Compiler
mkdir -p obj/CC3000_Host_Driver/
arm-none-eabi-gcc -g3 -gdwarf-2 -Os -mcpu=cortex-m3 -mthumb -I../CC3000_Host_Driver -I../SPARK_Firmware_Driver/inc -I../STM32F10x_StdPeriph_Driver/inc -I../STM32_USB-FS-Device_Driver/inc -I../CMSIS/Include -I../CMSIS/Device/ST/STM32F10x/Include -I. -ffunction-sections -Wall -Wno-switch -fmessage-length=0 -MD -MP -MF obj/CC3000_Host_Driver/cc3000_common.o.d -DUSE_STDPERIPH_DRIVER -DSTM32F10X_MD -DRELEASE_BUILD -c -o obj/CC3000_Host_Driver/cc3000_common.o ../CC3000_Host_Driver/cc3000_common.c
In file included from ../CC3000_Host_Driver/cc3000_common.c:46:0:
../CC3000_Host_Driver/cc3000_common.h:43:20: fatal error: stdlib.h: No such file or directory
#include <stdlib.h>
^
compilation terminated.
make[1]: *** [obj/CC3000_Host_Driver/cc3000_common.o] Error 1
make: *** [check_external_deps] Error 2
johnbo@k100rs ~/Projects/Spark/core-firmware/build $
Is there a set of environment variables that I’m supposed to define to give the compiler a path to the proper stdlib.h? I’m assuming that there are different stdlih.c files for the native compiler vs the arm version of the compiler.
This is probably something really obvious, but its been a loooonnnnnggg time since I built code for anything other than a native app.
This should be in your arm-none-eabi/include directory. I would look at your gcc install and path issues. I know that I have only the arm-none-eabi-…/bin directory on the path.
I get that error on Ubuntu when I install the distro’s arm package. Make sure you download and install the one from the website listed in the instructions.
oh yes the package is completely useless (they only just enabled c++ and it conflicts with regular gcc) don't use that crap, just extract the tarball and add gcc-arm-none-eabi/bin to your $PATH.
maybe we need to add this to the README.md along with removing the bit about using package managers to get dfu-util as 0.5 is useless too.
I had setup the system to use the specific PPA, but apparently apt-get was pulling the gcc-arm-none-eabi package from one of the ubuntu repositories. After a bit of googling, I removed/purged the old package and forced apt-get to get the specific package.
I used: sudo apt-get install gcc-arm-none-eabi=4-8-2014q1-0trusty8
This seems to have done the trick. I’m now able to do the build. As this is the first build, I’m assuming that the following size for a dead stock build should result in the following:
arm-none-eabi-size --format=berkeley core-firmware.elf
text data bss dec hex filename
70448 3100 12108 85656 14e98 core-firmware.elf
Interestingly, with the old package installed, the ‘normal’ include files were present. except stdlib.h was missing. With the proper package installed, the includes are in a different location and the stdlib.h is now present.
Just be careful when you do an apt-get upgrade. It’ll clobber the package from the PPA. I had to pin that specific version so that upgrades don’t kill it.
I actually like @sej7278’s method of installing so that there’s no conflict with the version in ubuntu’s repos and I’ll probably do that next time.
Thanks for the warning. I fiddled with the /etc/apt/preferences.d directory. I added a file called gcc-arm-none-eabi.pref with the following contents, to attempt to force apt-get to pull from the proper repository.
It initially seemed that that this held back the gcc-arm-none-eabi package, but after doing some testing by changing the name of the Package within the file, it seems to have no effect. Deleting the file has the same effect, in that the gcc-arm-none-eabi package is being held back. I did do the update/upgrade sequence between each change.
So, I guess that for whatever reason the system seems to be properly stuck at the version that I asked for. Not sure what happens when the PPA updates with a new version. I guess that I’ll have to cross that bridge when I come to it.
I just want to say, after an hour and a half stumbling around I found this thread and it solved my problem directly. I would highly encourage putting something about grabbing the specific version of the package on the docs.
