Alire on macOS, revisited
This note covers some of the considerations thatβll apply when running Alire on macOS.
Read more Β»This note covers some of the considerations thatβll apply when running Alire on macOS.
Read more Β»These are notes on building GCC 12.2.0 and GNAT tools for Apple silicon.
There were two main problems:
Recently, on the Gitter Ada Programming Language lobby, there have been discussions on cross-compiling for Cortex M micro-controllers, specifically the BBC micro:bit, using the Raspberry Pi.
TL;DR: it's not going to be easy, unfortunately. Maybe later (or earlier?) Raspbian releases will help.
Read more Β»This post is based on the README from the corresponding Github repository.
That repository attempts to cope with expected changes in Appleβs approach to software development kits, specifically where to find the system headers (youβd expect /usr/include).
Read more Β»After you've installed Xcode (or, my preference, the Command Line Tools via xcode-select -install) so that you can install and use GNAT, you may expect to be able to compile C code too.
Mojave may surprise you with
$ gcc casing.c -o casing casing.c:1:10: fatal error: stdio.h: No such file or directory 1 | #include <stdio.h> | ^~~~~~~~~ compilation terminated.
The reason, according to this question and its answers, is that Apple's developer tools, in particular the clang compiler, know where to find the include files under /Library/Developer; GCC doesn't (I'm sure it could be made to, but ...) and so we have to add an extra step to install them in the normal place:
$ sudo installer -pkg /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg -target / Password: installer: Package name is macOS_SDK_headers_for_macOS_10.14 installer: Installing at base path / installer: The install was successful.You may need to repeat this after macOS or Command Line Tools (or Xcode) updates.
Apple's software development tools are based on LLVM, and Apple don't seem to feel it necessary to keep GCC and friends up to date with changes in the Apple tools or security policies.
GDB has been particularly affected by this. You can see why a tool which is capable of interacting with running programs would have to be treated with caution.
Read more Β»We will do the following tasks:
First, prepare three distinct directories for the sources, the build materials and the installation. Make sure you have more than 1.5G for the source directory, reserve 7.0G for the build directory and arround 1.5G for the installation directory.
To simplify the commands, define the following shell variables:
BUILD_DIR=<Path of build directory> INSTALL_DIR=<Path of installation directory> SRC_DIR=<Path of directory containing the extracted sources>
Also, check that:
Create the directories:
mkdir -p $BUILD_DIR mkdir -p $INSTALL_DIR/bin mkdir -p $SRC_DIR
And setup your PATH so that you will use the new binutils and gcc commands while building everything:
export PATH=$INSTALL_DIR/bin:/usr/bin:/bin
Download binutils 2.26 and extract the tar.bz2 in the source directory $SRC_DIR.
cd $SRC_DIR tar xf binutils-2.26.tar.bz2
Never build the binutils within their sources, you must use the $BUILD_DIR for that. Define the installation prefix and configure the binutils as this:
mkdir $BUILD_DIR/binutils cd $BUILD_DIR/binutils $SRC_DIR/binutils-2.26/configure --prefix=$INSTALL_DIR
And proceed with the build in the same directory:
make
Compilation is now complete you can install the package:
make install
Download gcc 6.1.0 and extract the tar.bz2 in the source directory $SRC_DIR.
cd $SRC_DIR tar xf gcc-6.1.0.tar.bz2
Again, don't build gcc within its sources and use the $BUILD_DIR directory. At this stage, it is important that your PATH environment variable uses the $INSTALL_DIR/bin first to make sure you will use the new installed binutils tools. You may add the --disable-bootstrap to speed up the build process.
mkdir $BUILD_DIR/gcc cd $BUILD_DIR/gcc $SRC_DIR/gcc-6.1.0/configure --prefix=$INSTALL_DIR --enable-languages=c,c++,ada
And proceed with the build in the same directory (go to the restaurant or drink a couple of beers while it builds):
make
Compilation is now complete you can install the package:
make install
The Ada compiler installation does not install two symbolic links which are required during the link phase of Ada libraries and programs. You must create them manually after the install step:
ln -s libgnarl-6.so $INSTALL_DIR/lib/gcc/x86_64-pc-linux-gnu/6.1.0/adalib/libgnarl-6.1.so ln -s libgnat-6.so $INSTALL_DIR/lib/gcc/x86_64-pc-linux-gnu/6.1.0/adalib/libgnat-6.1.so
The gnatmake command has been deprecated and it is now using gprbuild internally. This means we need a version of gprbuild that uses the new compiler. One way to achieve that is by setting up a gprbuild configuration file:
cd $BUILD_DIR gprconfig
Select the Ada and C compiler and then edit the default.cgpr file that was generated to change the Toolchain_Version, Runtime_Library_Dir, Runtime_Source_Dir, Driver to indicate the new gcc 6.1 installation paths (replace <INSTALL_DIR> with your installation directory):
configuration project Default is ... for Toolchain_Version ("Ada") use "GNAT 6.1"; for Runtime_Library_Dir ("Ada") use "<INSTALL_DIR>/lib/gcc/x86_64-pc-linux-gnu/6.1.0//adalib/"; for Runtime_Source_Dir ("Ada") use "<INSTALL_DIR>/lib/gcc/x86_64-pc-linux-gnu/6.1.0//adainclude/"; package Compiler is for Driver ("C") use "<INSTALL_DIR>/bin/gcc"; for Driver ("Ada") use "<INSTALL_DIR>/bin/gcc"; ... end Compiler; ... end Default;
This is the tricky part because if you missed it you may end up using the old Ada compiler. Make sure the Runtime_Library_Dir and Runtime_Source_Dir are correct otherwise you'll have problems during builds. As far as I'm concerned, the gcc target triplet was also changed from x86_64-linux-gnu to x86_64-pc-linux-gnu. Hopefully, once we have built a new gprbuild everything will be easier. The next step is to build XML/Ada which is used by gprbuild.
Download and extract the XML/Ada sources. Using the git repository works pretty well:
cd $BUILD_DIR git clone https://github.com/AdaCore/xmlada.git xmlada
This time we must build within the sources. Before running the configure script, the default.cgpr file is installed so that the new Ada compiler is used:
cp $BUILD_DIR/default.cgpr $BUILD_DIR/xmlada/ cd $BUILD_DIR/xmlada ./configure --prefix=$INSTALL_DIR
And proceed with the build in the same directory:
make static shared
Compilation is now complete you can install the package:
make install-static install-relocatable
Get the gprbuild sources from the git repository:
cd $BUILD_DIR git clone https://github.com/AdaCore/gprbuild.git gprbuild
Copy the default.cgpr file to the gprbuild source tree and run the configure script:
cp $BUILD_DIR/default.cgpr $BUILD_DIR/gprbuild/ cd $BUILD_DIR/gprbuild ./configure --prefix=$INSTALL_DIR
Setup the ADA_PROJECT_PATH environment variable to use the XML/Ada library that was just compiled. If you miss this step, you'll get a file dom.ali is incorrectly formatted error during the bind process.
export ADA_PROJECT_PATH=$INSTALL_DIR/lib/gnat
And proceed with the build in the same directory:
make
Compilation is now complete you can install the package:
make install
Now you can remove the build directory to make some space. You'll not need the default.cgpr file anymore nor define the ADA_PROJECT_PATH environment variable (except for other needs). To use the new Ada compiler you only need to setup your PATH:
export PATH=$INSTALL_DIR/bin:/usr/bin:/bin
You're now ready to play and use the GCC 6.1 Ada Compiler.
The public version of the AdaCore Ravenscar RTS is released under the full GPL. It seemed as if it would be a good idea (and fun!) to produce an independent RTS with the GCC Runtime Library Exception(FAQ).
Read more Β»These notes describe building GCC 5.1.0 for the Cortex M4 on Mac OS X.
My target board is the STM32M4F29I Discovery.
Read more Β»These notes describe building GCC 5.1.0 for Mac OS X, with Ada, C, C++, Fortran, Objective C, Objective C++, and various GNAT tools.
Read more Β»AdaCore's doinstall is an excellent way of installing the compiler where you want to. Unfortunately, GCC 4.9 uses the shared libgcc_s.1.dylib, which has no @rpath-type constructs, and so the compiler executables expect to find libgcc_s.1.dylib in the place it was built for. (Not to mention libstdc++.6.dylib.)
Read more Β»