Building GNAT on MUSL, now with a signature »

Building GNAT on MUSL

15/01/18, modified 28/02/18

**Updated**: This version does not work!. Go here to the 2018-01-17 version

All of this, to be able to build the excellent FFA library. GNAT is an ADA compiler frontend, it is implemented on the GCC backend and working versions are provided by www.adacore.com1. MUSL is a C-library, and a lot smaller and more sane than the GNU C Library, it can be found here. Building the compiler takes some very specific steps which are implemented for you in a set of scripts2. These, you download, unpack and then build using ./ada-build.sh PREFIX-DIRECTORY. After a while you get executables in PREFIX-DIRECTORY/x86_64-linux-musl/bin.

As we are now in 2018, the 27th year of the linux, you will have problems. What follows is a short list
of the problems I encountered3

  1. GNAT needs GNAT. Download the binary 2016 version of gnat from the AdaCore website, unpack and add the path to the bin directory found within (DIR/gnat-gpl-2016-x86_64-linux-bin). Test it by running a gnat command like gnatmake. Now, re-run the ada-build.sh script.
  2. The gcc in GNAT cannot create executables. You have a new binutils version and the GNAT version of ld is incompatible. Copy the system linker (should be in /usr/bin/ld) to the libexec/gcc/x86_64-pc-linux-gnu/4.9.4 directory in the GNAT distribution.

With the script it is a lot easier to build GNAT on musl, it did take some headaches to get to this point

  1. The AdaCore distribution releases gcc and GNAT in separate files, a small script was needed to create a combined file for further processing
  2. The GNAT source code uses some C code and in this C code it uses GNU Library specific calls, these where easily changed to C/POSIX calls.4
  3. The multithreading code in GNAT is based on 1 non-portable call. This call has an implementation in the GNU library but not in the MUSL C library (to be able to change a preferred scheduling algorithm on read-write locks, specific function was pthread_rwlockattr_setkind_np and parameter PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP). This had to be commented out. Commenting out lead to style warnings (even comments are checked on style)
  4. The names of the gnattools (gnatmake / gnatbind / gnatlink) where hardcoded in the makefiles, these had to be changed to allow for different names and extra command line arguments.5
  5. The 2016 version of the gprbuild tool could only be built by an existing gprbuild tool, this was easily fixed by using the 2017 version. The 2017 version comes with a bootstrap script.
  6. The gprbuild tool uses a database of known compiler names6 these did not include a pattern for the compilers created by these scripts.

I hope not to have to touch or think of this code for a couple of months. This is enough reason for a small list of things to do for the next time.

  1. Let's remove all patches for old gcc versions and old musl libraries, leaving only 4.9.4.
  2. The current script builds cross compilers, instead or also make a native compiler without triples in the name.
  3. It seems that the 4.9.4 branch of gcc still receives updates, determine if these are relevant
  4. Move 2017 adacore to 4.9.4.
  5. Make the whole thing a V-patch.

And that's it.

  1. GCC also includes a version of GNAT, this version is derived (by way of some magic) from the AdaCore version. Unfortunately, if you want to know out how this derivation works, you find that the number of changed lines between the source code of GNAT releases (say 2014 and 2015) is large. This is also true for the number of changed lines between GNAT and GCC releases. Untangling this ball of twine will take some time and I worry about my sanity even starting such a task. Based on a cursory investigation, I pose that the GCC version is derived from a development version of GNAT between the 2014 and 2015 releases. For our purposes this GCC version is broken. [↩]
  2. The GNAT build scripts are derived from the original musl cross compiler build scripts, to be found here [↩]
  3. Feel free to add your problems in the comments below [↩]
  4. Easily, but slowly, some problems could only be found when rebuilding from scratch. [↩]
  5. All these tools build dynamicilly linked executables by default and I want static. [↩]
  6. In the form of regular expression statements in the file 'share/gprconfig/compilers.xml' [↩]

This entry was posted on Monday, January 15th, 2018 at 15:51 and is filed under Ada. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Leave a Reply