The adtools project
This is the Amiga developement tools project that host a number of tools that can be used to develop applications for AmigaOS and Amigaoid systems. At the moment only the version for the latest AmigaOS version (4.x) is in a relatively good shape while this is probably not the case for the other systems.
The main repo is still hosted on a SVN repository under https://sf.net/projects/adtools. It uses the concept of vendor branches but this is making quick progress nearly impossible, so a new approach is tested here.
In contrast to the original approch, build products that are based on other projects (e.g. gcc) are not imported directly into this repository. Instead only the patches that need to be applied to a given base version (e.g. stock gcc 6) are directly stored and maintained.
An lha archive with current binaries can be found at https://dl.bintray.com/sba1/adtools-native.
In order to install it on your Amiga, extract the archive to a destination of your
choice. Then establish a GCC: assignment to the extracted folder and add the contained
bin folder to the command search path
1> ASSIGN GCC: <extracted folder> 1> PATH GCC:bin add
Furthermore, you need to have an
SDK: assign as in the original SDK.
Note that if you use the
APPDIR: feature you should flush its contents. Otherwise,
you may observe unexpected behaviour. Most easily this can be achieved by entering
1> delete APPDIR:#?
Debian-based Linux distributions
Debian packages are generated automatically for the amd64 architecture. If not already done, add the Bintray key that is used to sign the package to your installation, e.g., via:
apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 379CE192D401AB61
deb http://dl.bintray.com/sba1/adtools-deb /
/etc/apt/sources.list file. For instance, enter:
$ echo "deb http://dl.bintray.com/sba1/adtools-deb /" | sudo tee -a /etc/apt/sources.list
Installation is then as easy as typing
$ aptitude install adtools-binutils adtools-sdk adtools-gcc
A very naive patch management system called
gild that should simplify the
management of patches has been developed in context of this project. In the
gild became a tiny project of its own and it is located at
http://github.com/sba1/gild. It is linked to this project using submodules
feature of git.
So in order to follow the build instructions, you need to make sure that the
gild directory is populated:
$ git submodule init $ git submodule update
With this, the softlink
bin being in your command
line path, you have access to the following commands:
gild list: lists available components and branches. For instance
$ gild list binutils 2.23.2 coreutils 5.2 gcc 4.9 gcc 5 gcc 6 gcc 8
shows that there are three components
gild clone: will fetch the external sources of all components into the respective
repodirectories. The checkout will not be affected.
gild checkout: will checkout for a specific component a specific branch to the working directory of the
repodirectory and apply the current patches for this branch. The result of this is what should be used for compiling. It can also be used to adjust the order and content of the patches e.g., using
git rebaseetc. For example, invoke
$ gild checkout gcc 8
to checkout the version 8 branch of gcc and apply all adtools patches for this branch. The gild tool will attempt a shallow clone of the remote repository if it doesn't exist locally.
You should also invoke this command if you want to reapply the current set of patches (e.g., after pulling changed patch sets).
gild genpatch: will generate the patches between the base checkout and the current HEAD of the repo. The patches are written to the
patchesdirectory of the respective component. For instance, invoke
$ gild genpatch gcc 8
to generate the tracked changes for 8 branch of gcc. The patches will
be located in
The local build is suitable when no packaging should be done. The easiest
approch involves invoking the
makefile provided in the
native-build folder. The procedure currently assumes that the sources
have previously been checked out and that the patches have been applied.
This can be done by:
$ bin/gild clone $ bin/gild checkout binutils 2.23.2 $ bin/gild checkout coreutils 5.2 $ bin/gild checkout gcc 8
You can also try
bin/gild checkout gcc 6 but this produces the more
experimental version of gcc 6. Building is then a matter of entering
$ make -C native-build
The building should succeed, if all dependencies are met (e.g.,
lha | lhasa).
If you just need a cross-compiler then call the
gcc-cross target like
$ make -C native-build gcc-cross
In this case, you also don't need to checkout the
component. In order to use the cross compiler, add the
path to your
PATH variable, e.g., like this:
$ export PATH=$PATH:$(pwd)/root-cross/bin
Note that you can change where the cross toolchain is located via the
CROSS_PREFIX macro. For instance,
$ make -C native-build gcc-cross CROSS_PREFIX=/opt/adtools
would install the toolchain into
/opt/adtools directory. Note that
the build process will write to this directory.
For creating an AmigaOS distribution archive, the
makefile in the
native-build folder is used as well. One prerequiste is that you
provide the current user access to a
/gcc folder, e.g., via
$ su $ mkdir /gcc $ chown <user> /gcc
Then, being in the
native-build folder, enter
$ make native-install ... $ make native-dist ... $ make clib2-dist ...
This will write some files into
/gcc folder and create the
distribution archives suitable for
lha for the entire toolchain
inclusive a custom archive for the clib2 static link library. List them
$ ls *.lha adtools-os4-20180405-458.lha adtools-os4-clib2-20180405-458.lha
For Debian-based distributions
Debian packaging is provided in
packaging/deb. There also some Docker
scripts, however, they may not work correctly at the moment.