freddiechopin/bleeding-edge-toolchain

All-in-one script to build bleeding-edge-toolchain for ARM microcontrollers

bleeding-edge-toolchain

All-in-one script to build bleeding-edge-toolchain for ARM microcontrollers.

bleeding-edge-toolchain - what it's all about?

Toolchain for Linux

Due to the fact that building a binary on "Linux distribution A" that would work on "Linux distribution B" (where "Linux distribution B" may just be "Linux distribution A 6 months later after a few upgrades") is really hard (impossible?), there will be no binary packages for Linux. This script and some spare CPU time (~2 hours) is all you need.

To build native toolchain for Linux just run the script with no arguments:

./build-bleeding-edge-toolchain.sh

Most of the tools required by the script should be already present in your system, but some may be missing. Generally the tools listed below should be enough to successfully execute this script:

• obvious tools needed to compile anything - like gcc, binutils, make and coreutils
• m4, which is required to execute configure scripts
• curl, used to download the source tarballs of toolchain components
• tar, used to extract source tarballs and to compress a compiled toolchain
• texinfo and texlive, (optional) used to generate documentation
• python, required by GDB, may be either version 2 or 3, but should contain headers and libraries, so you may need some kind of "development" and/or "library" package, depending on your system

The exact set of required packages will be different on each system, but on a fresh Ubuntu installation you are going to need just these packages: curl, m4, python2.7-dev and optionally: texinfo and texlive.

Toolchain for Windows

As Windows is at the opposite end of spectrum when it comes to binary compatibility, the packages for 32-bit and 64-bit Windows are available on bleeding-edge-toolchain's website in Releases. If you choose the easy path, just download an archive, extract it with 7-zip and add .../bin folder to your system's PATH environment variable.

If you want to also build a toolchain for 32-bit and/or 64-bit Windows pass --enable-win32 and/or --enable-win64 as arguments for the script, like this:

./build-bleeding-edge-toolchain.sh --enable-win32 --enable-win64

Such compilation has more dependencies:

• Mingw-w64, namely i686-w64-mingw32-gcc (for 32-bit version) and/or x86_64-w64-mingw32-gcc (for 64-bit version) with their own dependencies (binutils, headers, ...)
• libtermcap and libwinpthread compiled for Mingw-w64
• p7zip, used to compress the toolchain into an archive in .7z format

Additional options

• --keep-build-folders will cause all build folders to be left intact after the build, by default - if this option is not provided - all build folders are removed as soon as they are not needed anymore
• --resume will try to resume the last (interrupted) build instead of starting from scratch; be advised that this option is experimental and may not work reliably in all possible cases - if in doubt or in case of strange errors just don't use it to perform a clean build
• --skip-documentation will skip building html/pdf documentation in the subprojects, by default - if this option is not provided - the documentation is built, requiring texlive/texinfo
• --skip-gdb will skip building gdb, which may be unnecessary if your Linux distribution already has a multiarch gdb
• --skip-nano-libraries will skip building of "nano" libraries, by default - if this option is not provided - "nano" libraries will be built, making the whole process take significantly longer
• --quiet will make the build slightly less noisy

bleeding-edge-toolchain's Issues

Why not Makefile based?

I use Makefiles to do some build script, code looks much cleaner than generic shell:
https://github.com/ponyatov/NUC970_NonOS_BSP/tree/GNU/gnu

Python, pushd error

checking whether to use python... yes
checking for python... /usr/bin/python
CC libctf_la-ctf-open.lo
CC libctf_la-ctf-serialize.lo
checking for python... no
configure: error: python is missing or unusable
CC libctf_la-ctf-sha1.lo
make[1]: *** [Makefile:11124: configure-gdb] Error 1
make[1]: *** Waiting for unfinished jobs....

Does anybody know how to solve that, can anybody help?
Python is installed and previous versions compiled good.
That was the script changed by me.

Current script works as follows

********** Resuming last build
********** Download
********** Extract
---------- Patching gdb-12.1
./build-bleeding-edge-toolchain.sh: 813: pushd: not found
miha@ksonasu:~/allaccess/Gcc-12_t$

how to solve that?

System is Ubuntu 20.

GCC 12.2.0 / MacOS ARM64

gcc-12.2.0-final build stops with internal compiler error during libgcc build.

With gcc-12.1.0 it works.

Windows file flags

On Windows (e.g. in WSL) every file is mapped as executable.
Hence lines like

bleeding-edge-toolchain/build-bleeding-edge-toolchain.sh

Line 1060 in 7061c04

find ${installFolder} -executable ! -type d ! -name '*.exe' ! -name '*.dll' ! -name '*.sh' -exec rm -f {} +

fail, removing too much, and this is really slow:

bleeding-edge-toolchain/build-bleeding-edge-toolchain.sh

Line 885 in 7061c04

find ${installNative} -type f -executable -exec strip {} \; || true

Dwarf Error: Could not find abbrev number

With the standard Ubuntu 19.04 arm-gcc (7.3.1) there's no error. So I'd say it's either a regression in gcc 9 or something is wrong with the way you build the C library.

extern "C"
int _exit(){}
int main() {}
class HardwareSerial3 {
int available() { }
};
void yield() {}

arm-none-eabi-g++ -o main.cpp.o -c -fno-exceptions -felide-constructors -fno-rtti -std=gnu++14 -Wno-error=narrowing -flto -g -ffunction-sections -fdata-sections -mthumb -mcpu=cortex-m4 -nostdlib -O2 main.cpp
arm-none-eabi-g++ -o firmware.elf -g -Wl,--gc-sections,--relax -mthumb -mcpu=cortex-m4 -O2 --specs=nano.specs -Wl,--start-group main.cpp.o -lm -lstdc++ -Wl,--end-group
arm-none-eabi-nm -ClS --radix=d --size-sort firmware.elf

Integration with CLion

I look for the best way to integrate toolchain with CLion IDE (currently 2020.1.1)

Previously I had this configuration:

Anyway IDE was compiling based on gnu-eabi present in the system
Now for stability and compatibility I want assure recomended toolchain

-flto -g fails

I tested the toolchain, thanks for it!
It even saves 2-3KB compared to my older 8.2 toolchain.
LTO works too but not when adding debug info (worked with the older toolchain). Can you reproduce this?
arm-none-eabi/bin/ld.exe: error: could not unlink output file

Crosscompile the crosscompiler

First of all, thanks for a great script - works perfectly!

Now, I want to compile a cortex-m4 compiler - on a raspberry. Needless to say, it takes quite some time, and I would love to tinker around with library versions in order to tailor my toolchain. So, I was thinking that I could perhaps cross compile the m4 cross compiler for raspberry on my lightning-fast Linux can. Yeah, sounds fun doesn't it! ;)

Anyhow, to make things easy I got the/a/some raspberry toolchain simply by
sudo apt install gcc-arm-linux-gnueabihf which gives me a toolchain with sysroot and everything. Pretty nifty. (I do realize that I need to make the rpi crosscrosstoolchain running on my pc properly with headers according to my rpi system, but that's a later issue)

So, I happily pointed out my rpi compiler and ran the script

$ export CC=/usr/bin/arm-linux-gnueabihf-gcc
$ export CXX=/usr/bin/arm-linux-gnueabihf-g++
$ export LD=/usr/bin/arm-linux-gnueabihf-ld
$ ./build-bleeding-edge-toolchain.sh 

Which didn't really play along - GMP complains about
configure: error: could not find a working compiler, see config.log for details

Looking in the config.log gives us

int main () { return 0; }
configure:6962: result: no
configure:5858: checking compiler /usr/bin/arm-linux-gnueabihf-gcc -O2 -pedantic -fomit-frame-pointer -pipe 
Test compile: 
configure:5872: /usr/bin/arm-linux-gnueabihf-gcc -O2 -pedantic -fomit-frame-pointer -pipe  conftest.c >&5
configure:5875: $? = 0
configure:5880: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest
/lib/ld-linux-armhf.so.3: No such file or directory
/home/petera/proj/ub-toolchain/bleeding-edge-toolchain-xcomp/sources/gmp-6.1.2/configure: line 5881: ./b.out: No such file or directory
/home/petera/proj/ub-toolchain/bleeding-edge-toolchain-xcomp/sources/gmp-6.1.2/configure: line 5881: ./a.exe: No such file or directory
/home/petera/proj/ub-toolchain/bleeding-edge-toolchain-xcomp/sources/gmp-6.1.2/configure: line 5881: ./a_out.exe: No such file or directory
/home/petera/proj/ub-toolchain/bleeding-edge-toolchain-xcomp/sources/gmp-6.1.2/configure: line 5881: ./conftest: No such file or directory
configure:5883: $? = 127
failed program was:

int main () { return 0; }
configure:6962: result: no, program does not run
configure:7200: error: could not find a working compiler, see config.log for details

where I believe this is the culprit:

configure:5880: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest
/lib/ld-linux-armhf.so.3: No such file or directory

Seems configure is actually trying to run the test binary it just built, which obviously fails as we are on a different target.

So, my question is - how do I get around this? I've been looking through libGMPs sites but cannot really find anything useful. Can you give me a nudge forward?

I tinkered around a bit around here but to no avail.

Of course, would you find that this is an all too odd request, I totally understand if you simply roll your eyes and close this issue directly. 😄

Cheers!

runtime dll copy

I'm not sure what this is supposed to do:

bleeding-edge-toolchain/build-bleeding-edge-toolchain.sh

Line 1061 in 7061c04

dlls="$(find ${installFolder}/ -name '*.exe' -exec ${triplet}-objdump -p {} \; | sed -ne "s/^.*DLL Name: \(.*\)$/\1/p" | sort | uniq)"

• The sed part should use single quotes. Not sure how this ever worked.
• On Linux it's trying to copy dlls from /usr/x86_64-w64-mingw32/bin/ which don't exist of course.
• Will there ever be any runtime dlls required? Shouldn't it produce "static" executables?
• Otoh it does not copy sources/python-2.7.16.amd64/python27.dll which it probably should (?) to produce a self-contained package.

Building also Cortex-A and big-endian Cortex-R / Restart build

1)Do you have a hint how to build for all Cortex-M/R/A and big-endian.
I see you use mrprofile? Can one add additional profiles?

2. I see no way to restart a build. It always starts all over (at least not downloading).
   Did I miss it?

gdb TUI?

Any reason for not enabling the text UI with --enable-tui? :)

Docker

Hi!

this is more a question then an issue but... Did you think about dockerize entire toolchain with IDE and all kind of good stuff?

newlib semihosting

Thank you for publishing this script. It was a great help in writing my script to build an ARM toolchain.

I have a question. I am trying to use my own toolchain as a replacement for a toolchain supplied by NXP inside their MCUXpresso. It has libcr_newlib_semihost.a, libcr_newlib_nohost.a, and libcr_newlib_none.a. These are not being built by your script. Do you have a clue how to build them?

build errors on openSUSE Leap 42.2

Hi!
build-bleeding-edge-toolchain.sh faild to build on my system, It seams that on opensuse libraries needs to be located in ${top}/${buildFolder}/${prerequisites}/${<NAME>}/lib insted of ${top}/${buildFolder}/${prerequisites}/${<NAME>}/lib64

the workaround is to add ln -s ${top}/${buildFolder}/${prerequisites}/${<NAME>}/lib64 ${top}/${buildFolder}/${prerequisites}/${<NAME>}/lib for GMP, MPFR, MPC, ISL and EXPAT libraries

I don't provide an diff for this workaround, because I don't know haw would it impact other systems.

Request that downloads be verified, with GnuPG when available.

Hello,

Many packages are downloaded in an insecure manner and left unverified. I would appreciate signature verification if it is not too cumbersome to add. Inasmuch as there are users of this script, such an addition would benefit those users.

I may be able to submit a pull request if I have time, but my immediate interest is, hopefully, being able to take the proper configuration this project describes and add that to crossdev, which integrates with portage and has signature verification for downloaded packages.

Linking issues between Linux and Windows built binaries

We have in our project stumbled on an linking issue when trying to link an locally (Windows) compiled arm target application with an library built on a CI server (linux). The linker error is:
lto1.exe: fatal error: LTO_tags out of range: Range is 0 to 420, value is 0

The linux server compiles the library using the toolchain built with the build-bleeding-edge-toolchain.sh script. On Windows we use the readily available binaries for the bleeding edge gcc.

This issue seems to only persist when the library and the application are compiled on separate machines. Building both the library and the application on the server works without any error. Same on Windows. Presumably this problem is somehow related to the gcc toolchain. Perhaps it might even be some sort of bug in the toolchain..

We spent some time trying to compile the Windows gcc version with the build-bleeding-edge-toolchain.sh script (in mingw64) but there seemed to be quite a lot of issues with the toolchain dependencies. Also trying to cross compile the bleeding edge gcc on MacOS for Windows seemed problematic.

Any suggestions for how to tackle this issue?
Our aim was to compile the bleeding edge gcc with some minor modifications to try and poke at the linking issue.