Problems with RTEMS toolchain build 4.12 & 5 incl. Ada support
chris at kluge-rocks.de
chris at kluge-rocks.de
Sat Dec 1 21:09:22 UTC 2018
Hi Sebastian, Chris, Thanassis and William,
first of all thank you for the warm welcome to the mailing list and the quick response on my request! Your remarks and tips really motivated me to continue and not give up. Sorry for the late reply but I couldn't try and test earlier because of my job.
I was aware of the fact that a native GCC+Ada is required with the same version to successfully build the toolchain but I obviously lost track while testing all those different scripts and approaches with a wild mix of versions (binutils, gdb, mpfr, ...). My lack of experience regarding use of different versions of GCC within a single environment lead to inconsistencies. Additionally, I was never sure that building RTEMS toolchain with Ada really worked for current RSB master.
Nevertheless, your tips pointed me to the right direction and I'm glad to say that I was able to successfully build the desired toolchain with nothing but RSB for rtems-sparc targets :-)!! This target is not the one I originally intended to build, but I wanted to first use this to ensure that the build process is not affected by possible side-effects caused by others.
Find some info on my steps below:
1) Preparation of the build environment
To be sure to use a consistent GCC7/GNAT7 toolchain for the build, I decided to use Ubuntu 18.04 minimal distribution. I installed gcc7 and used update-alternatives to "activate" it for the environment. Additionally, I installed all prerequisite packages which were not installed.
I identified the following package list during the build. I've not yet checked which packages are mandatory but preinstalled in the Ubuntu 18.04 minimal distribution.
sudo apt install gcc-7 g++-7 gnat-7 texinfo pax \
libncurses5 make git cmake make \
python3.6 python3.6-dev \
libreadline libreadline-dev # might not require dev package?
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-7 60 --slave /usr/bin/g++ g++ /usr/bin/g++-7
sudo update-alternatives --config gcc
Before installing libreadline(-dev), I experienced issues related to undefined symbols, e.g. tputs. I found some info on that in bug reports from 2012 but wasn't sure if they really were related to my problem (could be an issue of Ubuntu only and not occur in Debian).
2) Toolchain build with RSB
I fetched current master of RSB from github, entered sub-folder rtems/ and called sb-set-builder like this to run the build:
$(realpath ../)/source-builder/sb-set-builder --prefix=/opt/rtems/5 5/rtems-sparc --with-ada
The realpath construction might not be required, I'll check this this weekend but skipped detailled analysis in order to get results as fast as possible. I will come back on this soon/
After building GCC, the build process failed when cleaning up due to missing write permissions (info: didn't use any root privileges for the build). I then changed permissions for all files and folders within RSB base directory and restarted the build which then completed without any errors (didn't clean up, just ran sb-set-builder again).
3) What I learned from this approach
- don't be afraid to contact the community in case of issues
- make sure that all of GCC's components' versions really really match the desired toolchain version
- don't use AdaCore's GNAT GPL GCC binaries for the build, use the packages provided by the distribution
In general, those are the next steps for me:
- create a list of all packages required for the build
- use Debian instead of Ubuntu for the build
- try to build for other targets than sparc (arm, x86_64)
- test toolchain, either with qemu or real hw
- check why the issue related to access rights while cleaning up occurred
- update/create scripts and some documentation on the build and provide them to public via github.com (or any other way if this is not intended by RTEMS project?), maybe I could also provide a Dockerfile
I'll try to provide all of this as soon as possible but this depends on the time I can afford on this. At work, I've not had the possibility to use RTEMS at my job (automation industry) yet, so it's unfortunately just for fun and education for me currently. Nevertheless, I really like the RTEMS project and won't hesitate to inform you once I got something worth to contribute.
Once again thank you all for your effort to help me and feel free to ask if there's anything I missed to describe!
More information about the users