Evening, I figure I should summarise the state of the world wrt toolchains and SDKs for cross compiling things.
There are currently build runes for arm-unknown-riscos, m68k-unknown-amigaos, and ppc-amigaos toolchains. Of the latter two, the m68k one is for AmigaOS3 (and uses clib2 for its runtime) and the ppc one is for AmigaOS4 (and uses newlib for its runtime). The NetSurf SDK comprises all the third party libraries we link against (but not the base platform runtime, which is part of the toolchain) There are SDK build runes for all the above targets. The SDK makefile assumes that the toolchain is already installed. You must specify GCCSDK_INSTALL_CROSSBIN and GCCSDK_INSTALL_ENV when building the SDK so that it finds the correct toolchain and installs into the correct place. GCCSDK_INSTALL_CROSSBIN points at the bin directory containing the installed toolchain (e.g. /opt/netsurf/ppc-amigaos/cross/bin) GCCSDK_INSTALL_ENV points at the directory into which the SDK should be installed (e.g. /opt/netsurf/ppc-amigaos/env) Given that we've now got two amiga targets, there's a slight change needed when building our libraries and NetSurf itself for AmigaOS3: make TARGET=amigaos3 This is so we can dispatch to the correct tooling. At some point, it may well be worth turning HOST and TARGET into full host triplets. The AmigaOS4 build should be unaffected by this change. If anyone else has already cross-compiled stuff for AmigaOS3 then you'll need to make TARGET=amiga clean before attempting any AmigaOS4 builds of things. As ever, if you want to build for a specific target using your own tooling or build environment, then you'll can specify GCCSDK_INSTALL_CROSSBIN and GCCSDK_INSTALL_ENV when invoking make, or override individual tools in the normal way (e.g CC=clang) I'll be adding further toolchains targetting our supported platforms as the need arises. The end goal of all this nonsense is to trigger a build for every supported platform for every changeset in SVN. This will enable us to catch platform-specific build breakages at the earliest opportunity. I dare say we'll eventually extend the infrastructure to do other fun continuous integration things like running automated regression tests. J.
