adtools / amigaos-cross-toolchain

AmigaOS cross compiler for Linux / MacOSX / Windows

AmigaOS cross compiler for Linux / MacOSX / Windows

Author: Krystian Bacławski

This project is missing a maintainer! Want to become one? Ask adtools developer team!

Short description: Cross toolchain build script for AmigaOS m68k and ppc targets. Supported host platforms are Linux, MacOSX and Windows (with MSYS2).

Overview

amigaos-cross-toolchain project provides an easy way to build AmigaOS 3.x (m68k) and ppc AmigaOS 4.x (ppc) target toolchain in a Unix-like environment.

Build process should produce following set of tools for m68k-amigaos target:

• gcc 2.95.3
• g++ 2.95.3
• libstdc++ 2.10
• binutils 2.14 (assembler, linker, etc.)
• libnix 2.2 (standard ANSI/C library replacement for AmigaOS)
• libm 5.4 (provides math library implementation for non-FPU Amigas)
• AmigaOS headers & libraries & autodocs (for AmigaOS 3.9)
• vbcc toolchain (most recent release) including vasm, vlink and C standard library
• IRA: portable M68000/010/020/030/040 reassembler for AmigaOS hunk-format executables, libraries, devices and raw binary files
• vda68k: portable M68k disassembler for 68000-68060, 68851, 68881, 68882
• amitools with vamos AmigaOS emulator which is proven to run SAS/C

... and following set of tools for ppc-amigaos target:

• gcc 4.2.4
• g++ 4.2.4
• binutils 2.18 (assembler, linker, etc.)
• newlib
• clib 2.2
• AmigaOS headers & libraries & autodocs (for AmigaOS 4.1)

Note: Patches are welcome!

Downloads

There are no binary downloads provided for the time being. I do as much as possible to make the toolchain portable among Unix-like environments. Following platforms were tested and the toolchain is known to work for them:

• Windows 7 SP1 32-bit (MSYS2 2.6.0, gcc 5.3.0)
• Ubuntu 16.04 LTS 32-bit (gcc 5.4.0)
• Ubuntu 16.04 LTS 64-bit (gcc 5.4.0) Requires gcc-multilib package, and i386 libraries!
• MacOS X 10.9.5 (MacPorts - Apple's clang-600.0.57)

Documentation

Documentation from Free Software Fundation:

• gcc 2.95.3
• binutils

Texinfo documents from GeekGadgets converted into HTML:

• libnix - a static library for GCC on the amiga
• AmigaOS-only features of GCC

AmigaOS specific documents:

• Amiga Developer Docs

Compiling

Firstly… you should have basic understanding of Unix console environment, really ;-)

Prerequisites

You have to have following packages installed in your system:

• GNU gcc 5.x 32-bit version! or Clang
• Python 2.7.x
• libncurses-dev
• python-dev 2.7
• GNU make 4.x
• perl 5.22
• git
• GNU patch
• GNU gperf
• GNU bison

For MacOSX users: you'll likely need to have MacPorts or Homebrew installed in order to build the toolchain.

How to build?

Warning: Building with sudo is not recommended. I'm not responsible for any damage to your system.

Follow steps listed below:

1. Fetch amigaos-cross-toolchain project to your local drive:

    # git clone git://github.com/cahirwpz/amigaos-cross-toolchain.git
    # cd amigaos-cross-toolchain

2. Run toolchain-m68k or toolchain-ppc script (with --prefix option to specify where to install the toolchain). Note, that the destination directory must be writable by the user.

    # ./toolchain-m68k --prefix=/opt/m68k-amigaos build

3. Wait for the result :-)

4. (optional) Install additional SDKs (e.g. AHI, CyberGraphX, Magic User Interface, etc.):

    # ./toolchain-m68k --prefix=/opt/m68k-amigaos install-sdk ahi cgx mui

What if something goes wrong?

If the build process fails, please write me an e-mail. I'll try to help out. Don't forget to put into e-mail as much data about your environment as possible! It's vitally important to send me a full log from build process. You can capture it by redirecting output to a file with following command:

    # ./toolchain-m68k build 2>&1 | tee build.log

... but remember to cleanup your build environment beforehand with:

    # rm -rf .build-m68k

amigaos-cross-toolchain's Issues

issue in installing warp3d sdk

After successfully completing the build command, I do:
./toolchain-m68k --prefix=/home/me/xx install-sdk warp3d
It fails like this:
[code]
INFO: adding ".build-m68k/host/lib/python2.7/site-packages" to python site dirs
DEBUG: enter directory ".build-m68k/archives"
INFO: download: Warp3DDev-4.2a.lha (size: 336203)
......
DEBUG: enter directory ".build-m68k/sources/Warp3DDev-4.2a"
DEBUG: copy ".build-m68k/sources/Warp3DDev-4.2a/Warp3D_Devel/Docs/Warp3D.doc" to "../../xx/doc/Warp3D.doc"
DEBUG: copy ".build-m68k/sources/Warp3DDev-4.2a/Warp3D_Devel/Docs/Warp3D.guide" to "../../xx/guide/Warp3D.guide"
DEBUG: copy ".build-m68k/sources/Warp3DDev-4.2a/Warp3D_Devel/Docs/Warp3D_Devel.guide" to "../../xx/guide/Warp3D_Devel.guide"
DEBUG: copy ".build-m68k/sources/Warp3DDev-4.2a/Warp3D_Devel/Include/clib/Warp3D_protos.h" to "../../xx/os-include/clib/Warp3D_protos.h"
DEBUG: copy ".build-m68k/sources/Warp3DDev-4.2a/Warp3D_Devel/Include/fd/Warp3D.fd" to "../../xx/os-lib/fd/Warp3D_lib.fd"
DEBUG: makedir "../../xx/os-include/Warp3D"
DEBUG: copy ".build-m68k/sources/Warp3DDev-4.2a/Warp3D_Devel/Include/Warp3D/Warp3D.h" to "../../xx/os-include/Warp3D/Warp3D.h"
INFO: fd2sfd: "Warp3D_Devel/Include/fd/Warp3D_lib.fd" "Warp3D_Devel/Include/clib/Warp3D_protos.h" -> "Warp3D_lib.sfd"
DEBUG: execute "fd2sfd -o Warp3D_lib.sfd Warp3D_Devel/Include/fd/Warp3D_lib.fd Warp3D_Devel/Include/clib/Warp3D_protos.h"
Couldn't open file 'Warp3D_Devel/Include/fd/Warp3D_lib.fd'.
ERROR: command "fd2sfd -o Warp3D_lib.sfd Warp3D_Devel/Include/fd/Warp3D_lib.fd Warp3D_Devel/Include/clib/Warp3D_protos.h" failed with 1
[/code]

I then go into .build-m68k/sources/ and manually copy Warp3D.fd and Warp3D_lib.fd
and reissue the same command, then it succeeds.

Is it something wrong at my end, or is it a glitch with the python scripts?

BTW, you should use 4.2 version instead of 4.0, i.e. warp3d.sdk should change like:
Version: 4.2
Url: http://aminet.net/dev/misc/Warp3DDev-4.2a.lha

cybergraphics.h missing 'WritePixelArrayAlpha'

Latest versions of the cybergraphics.library API also contain a WritePixelArrayAlpha function at 0xd8. The required inlines are however missing in m68k-amigaos/ndk/include/inline/cybergraphics.h.

In other versions of the inline/cybergraphics.h file WritePixelArrayAlpha is defined as:

#define WritePixelArrayAlpha(srcRect, SrcX, SrcY, SrcMod, a1arg, DestX, DestY, SizeX, SizeY, AlphaValue) \
    LP10(0xd8, ULONG, WritePixelArrayAlpha, APTR, srcRect, a0, UWORD, SrcX, d0, UWORD, SrcY, d1, UWORD, SrcMod, d2, struct RastPort *, a1arg, a1, UWORD, DestX, d3, UWORD, DestY, d4, UWORD, SizeX, d5, UWORD, SizeY, d6, ULONG, AlphaValue, d7, \
    , CYBERGRAPHICS_BASE_NAME)

It would be great if this definition could be added to the cybergraphics.h file your toolchain is installing per default.

Please add "__amigaos3__" define to GCC patchset

For convenience reasons it would be great if you could add a default __amigaos3__ define to the GCC patchset. AmigaOS3 has __amigaos4__ and MorphOS has __MORPHOS__ defined by default. To better distinguish between different OS compilations it would be great to have __amigaos3__ defined per default for the GCC 2.95.3 patchset you are using for your cross toolchain.

-mcrt=clib2-ts (thread safe variant) required

For certain projects we do require the thread safety support of clib2 which however means that clib2 would have to be compiled with different compiler flags (-D__THREAD_SAFE).

For convenience and to not impact processing performance you could simply compile a "clib2-ts" variant together with the normal "clib2" version you supply anyway. To select the right clib2 version a developer could then easily choose the thread safe variant of clib2 by specifying -mcrt=clib2-ts which in fact we would do.

clean up directory structure for prefix installation

I just noticed that I have an m68k-amigaos inside my /opt/m68k-amigaos directory. It seems to have a fairly small number of files (ar, as, nm, ld and a few other binaries, plus the os-includes and libnix/clib2 directories).

I'm mildly sure this is wrong, but I wanted to check before I start digging into the build script.

./toolchain-ppc build doesnt work

DEBUG: makedir "ppc-amigaos"
Traceback (most recent call last):
File "./toolchain-ppc", line 241, in
globals()[action].call(*args.args)
AttributeError: 'Namespace' object has no attribute 'args'

gcc-2.95.3: clib2 support

While building the m68k gcc-2.95.3 toolchain defaults to libnix/ixemul building only, it should be noted that it can be quite easily tuned to also compile with clib2 (https://github.com/adtools/clib2) which is also available for os3-m68k and which is already widely used for compiling certain OS3 projects (YAM, MUI, AmiSSL, etc.).

Thus, it would be great if there would be an option to also build the toolchain with clib2 compatibility so that we don't have to manually tune the build environment afterwards to integrate clib2 support.

gcc-2.95.3: baserel compiling doesn't put const data into .text section

When using baserel compiling options like -fbaserel32 the GCC 2.95.3 m68k-amigaos cross compiler is not putting const data into the .text section like this is done for the non-baserel compiling case.

However, especially when using baserel compiling for creating a shared library that contains global data (e.g. like AmiSSL) results into some trouble. While other baserel-aware compiler suite for e.g. OS4 put const data correctly into a read-only or .text section, the current GCC 2.95.3 baserel support doesn't do that and thus results into some severe problems when using it for baserel compiling.

One example where this is causing problems is documented here:

jens-maus/amissl#1

There is also a short example source code added demonstrating the problem.

python-dev is required

Just pointing this out again in case you missed it: it seems that the check for python-dev was required after all, for python-lhafile/lzhlib.c.

Intermittent errors on Cygwin

OSError: [Errno 11] Resource temporarily unavailable

I'm suddenly getting a lot of these. They come and go as I rerun the build script. Just putting it up here in case someone can figure it out. Full error log is here.

error with stddef.h include (include order issue)

This is OK:

$ cat 0.c
#include <stdlib.h>
#include <stddef.h>
$ PATH=/opt/m68k-amigaos/bin:$PATH m68k-amigaos-gcc -c 0.c

This is not:

$ cat 0.c
#include <stddef.h>
#include <stdlib.h>
$ PATH=/opt/m68k-amigaos/bin:$PATH m68k-amigaos-gcc -c 0.c
In file included from /opt/m68k-amigaos/lib/gcc-lib/m68k-amigaos/2.95.3/../../../../m68k-amigaos/sys-include/stdlib.h:40,
                 from 0.c:2:
/opt/m68k-amigaos/lib/gcc-lib/m68k-amigaos/2.95.3/../../../../m68k-amigaos/sys-include/machine/ansi.h:51: warning: `_BSD_PTRDIFF_T_' redefined
/opt/m68k-amigaos/lib/gcc-lib/m68k-amigaos/2.95.3/include/stddef.h:112: warning: this is the location of the previous definition
/opt/m68k-amigaos/lib/gcc-lib/m68k-amigaos/2.95.3/../../../../m68k-amigaos/sys-include/machine/ansi.h:52: warning: `_BSD_SIZE_T_' redefined
/opt/m68k-amigaos/lib/gcc-lib/m68k-amigaos/2.95.3/include/stddef.h:159: warning: this is the location of the previous definition
In file included from /opt/m68k-amigaos/lib/gcc-lib/m68k-amigaos/2.95.3/../../../../m68k-amigaos/sys-include/stdlib.h:43,
                 from 0.c:2:
/opt/m68k-amigaos/lib/gcc-lib/m68k-amigaos/2.95.3/../../../../m68k-amigaos/sys-include/sys/types.h:110: warning: redefinition of `size_t'
/opt/m68k-amigaos/lib/gcc-lib/m68k-amigaos/2.95.3/include/stddef.h:170: warning: `size_t' previously declared here
In file included from 0.c:2:
/opt/m68k-amigaos/lib/gcc-lib/m68k-amigaos/2.95.3/../../../../m68k-amigaos/sys-include/stdlib.h:52: conflicting types for `wchar_t'
/opt/m68k-amigaos/lib/gcc-lib/m68k-amigaos/2.95.3/include/stddef.h:255: previous declaration of `wchar_t'

move project over to adtools

I would like to request/ask you if you could consider moving your amigaos-cross-toolchain project over to the adtools project (https://github.com/adtools). IMHO this would be a better place for this project. In addition, it would be great if you could also move over your sub projects (gcc-2.95.3, etc.) to adtools. This would be very much welcome!

"checking whether we are cross compiling" return error under Cygwin

Hi there!

I am trying to build the m68k and PPC tool-chains but run into errors...

./toolchain-m68k --prefix=/opt/m68k-amigaos build

leads to

checking whether we are cross compiling... configure: error: in /home/Yann/Programming/C/Timberwolf/amigaos-cross-toolchain/.build-m68k/bui ld/m4-1.4.17': configure: error: cannot run C compiled programs. If you meant to cross compile, use--host'.
See `config.log' for more details
ERROR: command "/home/Yann/Programming/C/Timberwolf/amigaos-cross-toolchain/.build-m68k/sources/m4-1.4.17/configure --prefix=/home/Yann/Prog
ramming/C/Timberwolf/amigaos-cross-toolchain/.build-m68k/host" failed with 1

How can I specify the "host"?
Thanks!
Yann

m68k tool-chain cannot find C startup files on OSX

The build completes without errors on OSX El Capitan 10.11.2, but any simple invocation of the compiler and collect/ld stops with m68k-amigaos/bin/ld: cannot open crt0.o: No such file or directory, the full error message is here.

The tool-chain was built with ./toolchain-m68k --prefix=/Users/zeroblue/Amiga/Tools/GCC/ build, and the version numbers for some of the prerequisites:

ncurses @6.0_0 (active) platform='darwin 15' archs='i386'
This is perl 5, version 18, subversion 2 (v5.18.2) built for darwin-thread-multi-2level
patch 2.5.8
bison (GNU Bison) 2.3

The gigantic debug log from the build is here.

Any idea what has gone wrong?

gcc-4.9: port AmigaOS specific code from gcc 2.95.3

gcc-amigaos
libnix

Code generation options:

• -msmall-code - all branches use only 16-bit displacement, thus all code must fit into 64KiB,
• -fbaserel - data and bss segments are addressed through a4 register with 16-bit displacement, thus merged size of data and bss must be below 64KiB,
• -fbaserel32- data and bss segments are addressed through a4 register with displacement of 32-bit.

Function attributes:

• saveds - restore a4 register in any function called from outside where the register could've been trashed,
• regparm - pass arguments to function in registers if possible,
• interrupt - use rte instead of rts and save scratch registers on stack,
• amiga_interrupt - set condition codes before returning to AmigaOS interrupt handler.

Explicit register specification:

• modify parser to support asm keyword after function argument,
• modify code that generates function prologue / epilogue.

Check build dependencies

People frequently report a bug or mail me because they're lazy enough not to read prerequisites section :P

Make the script croak if a dependency is missing - especially libncurses5-dev.

C++ not usable with clib2

I've tried to use the new -mcrt=clib2 switch. Unfortunately I'm getting this really weird compile error in file new. Problem is a lot of the standard includes use it so it is very easily triggered. Here's an example:

#include <algorithm>
int main(int argc, char** argv) {
    return 0;
}

In file included from /usr/local/m68k-amigaos/lib/gcc-lib/m68k-amigaos/2.95.3/include/new.h:6,
                 from /usr/local/m68k-amigaos/lib/gcc-lib/m68k-amigaos/2.95.3/include/g++/stl_algobase.h:52,
                 from /usr/local/m68k-amigaos/lib/gcc-lib/m68k-amigaos/2.95.3/include/g++/algorithm:30,
                 from /home/mooseart/Documents/Projects/referenz/Test2/main.cpp:1:
/usr/local/m68k-amigaos/lib/gcc-lib/m68k-amigaos/2.95.3/include/new:28: `operator new' takes type `size_t' as first parameter
/usr/local/m68k-amigaos/lib/gcc-lib/m68k-amigaos/2.95.3/include/new:29: `operator new' takes type `size_t' as first parameter
/usr/local/m68k-amigaos/lib/gcc-lib/m68k-amigaos/2.95.3/include/new:32: `operator new' takes type `size_t' as first parameter
/usr/local/m68k-amigaos/lib/gcc-lib/m68k-amigaos/2.95.3/include/new:33: `operator new' takes type `size_t' as first parameter
/usr/local/m68k-amigaos/lib/gcc-lib/m68k-amigaos/2.95.3/include/new:38: `operator new' takes type `size_t' as first parameter
/usr/local/m68k-amigaos/lib/gcc-lib/m68k-amigaos/2.95.3/include/new:39: `operator new' takes type `size_t' as first parameter

Homebrew packages for amigaos-cross-toolchain

Hey!

Would you have any objections if I add the toolchain to Homebrew? I've got a formula pretty much ready to go, I'd just like to get your approval and ask about whether it would be possible to get some kind of tag system going.

At the moment I've just got it set up to build from revision a4bb242c2fe353bf2263d401fb1114053e38ad8ea7a7bbf47d29de8782b99a84 (i.e. the current at the time of writing), with an option to build from HEAD, but it might be helpful if there were at least some tags with known-good revisions that I can work against.

Thanks very much for putting this toolchain together, it's been super helpful :)

Cheers,
Chris

missing utilities

I did the build, which went with no errors. but I cant run the SDK install because its missing pushd/popd/lha

edit to add some info;

[$]> ./install-sdk.sh --prefix=/opt/m68k-amigaos ahi cgx mui
Installing 'ahi'...
mktemp: too few X's in template ‘ahi’
./install-sdk.sh: line 54: pushd: no other directory
./install-sdk.sh: line 58: lha: command not found

libdebug.a

libdebug.a (/lib/libdebug.a) would be a good addition to m68k toolchain.
Source and binary rpms: https://sourceforge.net/projects/arp2/files/gg-libdebug/

new install script fails

INFO: preparing files for "vclib"
DEBUG: enter directory ".build-m68k/tmp/tmpbppKN1"
INFO: extract files from ".build-m68k/archives/vclib.lha"
DEBUG: extract "vbcc_target_m68k-amigaos.info"
Traceback (most recent call last):
  File "./toolchain-m68k", line 605, in <module>
    globals()[action].__call__(*args.args)
  File "./toolchain-m68k", line 285, in build
    unpack('vclib', top_dir='vbcc_target_m68k-amigaos')
  File "/home/sgeorge/nas/outside/amigaos-cross-toolchain/common.py", line 37, in wrapper
    return fn(*args, **kwargs)
  File "/home/sgeorge/nas/outside/amigaos-cross-toolchain/common.py", line 349, in wrapper
    fn(*args, **kwargs)
  File "/home/sgeorge/nas/outside/amigaos-cross-toolchain/common.py", line 405, in unpack
    unarc(src)
  File "/home/sgeorge/nas/outside/amigaos-cross-toolchain/common.py", line 37, in wrapper
    return fn(*args, **kwargs)
  File "/home/sgeorge/nas/outside/amigaos-cross-toolchain/common.py", line 278, in unarc
    f.write(arc.read(item.filename))
  File "/usr/lib/python2.7/dist-packages/lhafile/lhafile.py", line 344, in read
    fin = BytesOrStringIO(self.fp.read(info.compress_size))
NameError: global name 'BytesOrStringIO' is not defined

looks like an issue in lhafile which is strange, and I dont know enough about python. BytesOrStringIO is an import from BytesIO. Python has a bytesio class so I dont know whats going on...

Build fails on Mac OS X Mavericks

On current Mac OS X Mavericks with up to date macports I do get the following error:

In file included from /Volumes/MacintoshHD0/amiga-toolchain/m68k-amigaos-toolchain/sources/binutils-2.9.1/ld/lexsup.c:32:
/Volumes/MacintoshHD0/amiga-toolchain/m68k-amigaos-toolchain/sources/binutils-2.9.1/ld/ldmisc.h:43:13: error: conflicting types for 'xexit'
extern void xexit PARAMS ((int));
            ^
/Volumes/MacintoshHD0/amiga-toolchain/m68k-amigaos-toolchain/sources/binutils-2.9.1/ld/../include/libiberty.h:118:31: note: previous declaration is here
__volatile__ libiberty_voidfn xexit;
                              ^
1 warning and 1 error generated.
make[1]: *** [lexsup.o] Error 1
make: *** [all-ld] Error 2

GCC Version:

$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix

libmui.a should be installed c-runtime-library (clib2 vs. libnix) independent.

To compile certain MUI-like projects the libmui.a stub library is required.

After having installed your toolchain I recognized that libmui.a is only available when using libnix:

/opt/m68k-amigaos/m68k-amigaos/libnix/lib/libb/libm020/libm881/libmui.a
/opt/m68k-amigaos/m68k-amigaos/libnix/lib/libb/libm020/libmui.a
/opt/m68k-amigaos/m68k-amigaos/libnix/lib/libb/libmui.a
/opt/m68k-amigaos/m68k-amigaos/libnix/lib/libm020/libm881/libmui.a
/opt/m68k-amigaos/m68k-amigaos/libnix/lib/libm020/libmui.a
/opt/m68k-amigaos/m68k-amigaos/libnix/lib/libb32/libm020/libmui.a
/opt/m68k-amigaos/m68k-amigaos/libnix/lib/libmui.a

If compiling with clib2 no libmui.a is available, however.

It would be great if libmui.a could also be available for clib2 linkage/compilation without having to copy it manually to /opt/m68k-amigaos/m68k-amigaos/clib2/lib/ afterwards.

build fails

with: http://pastebin.com/pGJxkP6w

I had to do some minor tweaks before this one, too but I can't get past this error, any ideas? It's Arch Linux 32-bit, that means all tools are mostly up-to-date with upstream.

compilation with -O1: `fixed or forbidden register 8 (a0) was spilled for class ADDR_REGS`

When compiling our MUI sources with -O1 we are receiving compiler error like:

Area.c:2747: fixed or forbidden register 8 (a0) was spilled for class ADDR_REGS.
Area.c:2747: This may be due to a compiler bug or to impossible asm
Area.c:2747: statements or clauses.
Area.c:2747: This is the instruction:
(insn/i 1548 1547 1549 (set (reg/v:SI 12 a4)
        (mem/s:SI (plus:SI (reg/v:SI 5 d5)
                (const_int 16 [0x10])) 0)) 42 {movsi+1} (nil)
    (nil))

gcc-2.95.3: integrate testsuite

GCC 3.0 and later offer a separate archive with tests. Integrate them with the build process, but make running testsuite optional.

Add SDI headers

Hi Krystian,

it would be really great if the SDI headers would be available in os-include as I use them often and have to install them every time I setup a cross toolchain.

The headers can be found here: https://github.com/adtools/SDI

I simply checkout the SDI repo in os-include to have the headers in a SDI sub-folder.

Thanks for considering,
Chris

Docker: first build attempt fails most of the time

When I build one of the recent commits (from a cleanly checked out repository), the first build attempt usually fails with the following messages, although not always (race condition?):

DEBUG: execute "/home/build/amigaos-cross-toolchain/submodules/libdebug/configure --prefix=/opt/m68k-amigaos/m68k-amigaos/libnix --host=m68k-amigaos"
DEBUG: restoring old value of environment variable "CC"
DEBUG: restoring old value of environment variable "AR"
DEBUG: restoring old value of environment variable "RANLIB"
Traceback (most recent call last):
  File "./toolchain-m68k", line 714, in <module>
    globals()[action].__call__(*args.args)
  File "./toolchain-m68k", line 446, in build
    from_dir='{submodules}/{libdebug}')
  File "/home/build/amigaos-cross-toolchain/common.py", line 37, in wrapper
    return fn(*args, **kwargs)
  File "/home/build/amigaos-cross-toolchain/common.py", line 355, in wrapper
    fn(*args, **kwargs)
  File "/home/build/amigaos-cross-toolchain/common.py", line 451, in configure
    execute(path.join(from_dir, 'configure'), *confopts)
  File "/home/build/amigaos-cross-toolchain/common.py", line 37, in wrapper
    return fn(*args, **kwargs)
  File "/home/build/amigaos-cross-toolchain/common.py", line 216, in execute
    subprocess.check_call(cmd)
  File "/usr/lib/python2.7/subprocess.py", line 536, in check_call
    retcode = call(*popenargs, **kwargs)
  File "/usr/lib/python2.7/subprocess.py", line 523, in call
    return Popen(*popenargs, **kwargs).wait()
  File "/usr/lib/python2.7/subprocess.py", line 711, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1343, in _execute_child
    raise child_exception
OSError: [Errno 26] Text file busy

When I run the build command a second time, the build goes through.

I can reproduce the problem since commit a008957, but wasn't able to reproduce it for commit 4ca4a90, so it might have been introduced in the former.

My build environment is an Ubuntu 16.04 Xenial Xerus with gcc 5.4 inside a Docker container (I'm unable to build it on my host system, as I cannot install the gcc:i386 without package conflicts).

As I have my Docker images on the hub, you can very easily reproduce my environment if you have Docker running:

The one that works:

docker run -it --rm blubberdiblub/amigaos-cross-toolchain-repository:4ca4a90 sh -c './toolchain-m68k --prefix=/opt/m68k-amigaos build || bash'

The one that fails most of the time:

docker run -it --rm blubberdiblub/amigaos-cross-toolchain-repository:a008957 sh -c './toolchain-m68k --prefix=/opt/m68k-amigaos build || bash'

If the build completes without error, the container just cleans itself up (--rm). If the build fails with an error, however, it will spawn a bash for investigation. After exit, the container is cleaned up as well.

add fd2pragma

Hi Krystian,

fd2pragma would be a very useful addition to your fine set of tools.
In contrast to sfdc it allows you to create inline files for VBCC from custom fd files (and lots more :))

Although its initially an Amiga program, the source is available and you can already compile it (with warnings) on your host as a cross tool.

The most recent source version I found is 2.195 contained in fd2pragma-mos on aminet.

Additionally, this tool would be a good candidate for the adtoolsgit repo...

Best,
Chris

-L during linkage doesn't take preference anymore

In previous version of the cross compiler using "-L

" and "-l" during linkage resulted in GCC taking the specified -L as a preference. With your toolchain, however, specifying -L still results in the compiler using its internal linker pathes as preference.

This has the negative effect, that e.g. for our YAM project (https://github.com/jens-maus/yam) our own clib2 replacement libs weren't taken but the global ones from /opt/m68k-amigaos/... which caused some severe trouble since we requiring the thread safe variant of clib2.

See here for the fix we applied recently.
jens-maus/yam@941adb5

It would therefore be a good idea to restore the old behavior in -L command-line options taking preference over the internal ones GCC specified for the c-runtime library used.

gcc-2.95.3: Internal compiler error: program cc1 got fatal signal 11

When trying to compile the latest development sources of AmiSSLv4 (https://github.com/jens-maus/amissl/tree/master) the GCC 2.95.3 cross-compiler for building AmiSSL for OS3/m68k suddenly stops with the following error message:

$ make -j1 OS=os3
[...]
m68k-amigaos-gcc -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSLDIR="\"AmiSSL:\"" -DENGINESDIR="\"AmiSSL:engines\"" -m68020-60 -msoft-float -DNO_INLINE_VARARGS -D__NO_NET_API -DB_ENDIAN -DOPENSSL_SYS_AMIGA -D__amigaos3__ -DOPENSSL_NO_STDIO -I../../include -I../../include/netinclude -W -Wall -O1 -g -gstabs -DBN_DEBUG -DCONF_DEBUG -DDEBUG  -resident32 -DAMISSL_COMPILE -I../../libcmt/include  -Iinclude -I../../openssl -I../../openssl/crypto/include -I../../openssl/include -Icrypto/include -c -o crypto/dh/dh_rfc5114.o ../../openssl/crypto/dh/dh_rfc5114.c
In file included from ../../openssl/crypto/dh/dh_rfc5114.c:63:
../../openssl/crypto/include/internal/bn_dh.h:6: warning: `extern' is not at beginning of declaration
m68k-amigaos-gcc: Internal compiler error: program cc1 got fatal signal 11
Makefile:3402: recipe for target 'crypto/dh/dh_rfc5114.o' failed

After some investigation it seems cc1 is crashing because of some baserel related stuff which if -resident32 or -fbaserel32 is removed immediately vanishes.

A more detailed investigation of this issue (with gdb debugging output) can be found at jens-maus/amissl#4

HTTP 403 during toolchain-m68k

Fresh clone and executing as described gives:
Traceback (most recent call last): File "./toolchain-m68k", line 651, in <module> globals()[action].__call__(*args.args) File "./toolchain-m68k", line 219, in build fetch(name, url) File "/Users/civic/Documents/Entwicklung/Amiga/amigaos-cross-toolchain/common.py", line 37, in wrapper return fn(*args, **kwargs) File "/Users/civic/Documents/Entwicklung/Amiga/amigaos-cross-toolchain/common.py", line 350, in wrapper fn(*args, **kwargs) File "/Users/civic/Documents/Entwicklung/Amiga/amigaos-cross-toolchain/common.py", line 369, in fetch download(url, name) File "/Users/civic/Documents/Entwicklung/Amiga/amigaos-cross-toolchain/common.py", line 37, in wrapper return fn(*args, **kwargs) File "/Users/civic/Documents/Entwicklung/Amiga/amigaos-cross-toolchain/common.py", line 232, in download u = urllib2.urlopen(url) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 154, in urlopen return opener.open(url, data, timeout) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 437, in open response = meth(req, response) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 550, in http_response 'http', request, response, code, msg, hdrs) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 469, in error result = self._call_chain(*args) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 409, in _call_chain result = func(*args) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 656, in http_error_302 return self.parent.open(new, timeout=req.timeout) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 437, in open response = meth(req, response) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 550, in http_response 'http', request, response, code, msg, hdrs) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 475, in error return self._call_chain(*args) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 409, in _call_chain result = func(*args) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 558, in http_error_default raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) urllib2.HTTPError: HTTP Error 403: Forbidden

warning: `GetOutlinePen' redefined

With the default NDK you are installing in your cross toolchain, the following warning occur during compilation of different Amiga projects I am maintaining (MUI, etc.):

In file included from /opt/m68k-amigaos/lib/gcc-lib/m68k-amigaos/2.95.3/../../../../m68k-amigaos/include/../ndk/include/proto/graphics.h:13,
                 from symbols.h:119,
                 from master.h:36,
                 from Area.c:33:
/opt/m68k-amigaos/lib/gcc-lib/m68k-amigaos/2.95.3/../../../../m68k-amigaos/include/../ndk/include/inline/graphics.h:576: warning: `GetOutlinePen' redefined
/opt/m68k-amigaos/lib/gcc-lib/m68k-amigaos/2.95.3/../../../../m68k-amigaos/include/../ndk/include/graphics/gfxmacros.h:120: warning: this is the location of the previous definition

By looking at the corresponding header files it seems to be viable to actually comment out the GetOutlinePen() define in gfxmacros.h:

/* synonym for GetOPen for consistency with SetOutlinePen */
//#define GetOutlinePen(rp) GetOPen(rp)

That's in fact what I am doing here to get rid of these warnings.

Fail to build libdebug on cygwin.

**DEBUG: enter directory ".build-m68k/build/libdebug"
DEBUG: execute "make"
cd /home/Mooseart/amigaos-cross-toolchain/submodules/libdebug && autoconf
autoconf: configure.in: No such file or directory
make: * [Makefile:76: /home/Mooseart/amigaos-cross-toolchain/submodules/libdebug/configure] Error 1
ERROR: command "make" failed with 2

Possible explanation could be that it fails to select the correct autoconf, running the bundled autoconf 2.13 instead of the installed 2.69. Supposedly old autoconf does not support existing configure.ac as input and there's no configure.in for libdebug. Builds fine on Ubuntu though.

flex-2.5.4 returns Error 410 'Gone'

Hello,
while running the py script tonight I ran into this error:

Traceback (most recent call last):
File "./toolchain-m68k", line 623, in
globals()[action].call(_args.args)
File "./toolchain-m68k", line 206, in build
fetch(name, url)
File "/Users/akiko/packages/amigaos-cross-toolchain/common.py", line 37, in wrapper
return fn(_args, *_kwargs)
File "/Users/akiko/packages/amigaos-cross-toolchain/common.py", line 350, in wrapper
fn(_args, *_kwargs)
File "/Users/akiko/packages/amigaos-cross-toolchain/common.py", line 369, in fetch
download(url, name)
File "/Users/akiko/packages/amigaos-cross-toolchain/common.py", line 37, in wrapper
return fn(_args, *_kwargs)
File "/Users/akiko/packages/amigaos-cross-toolchain/common.py", line 232, in download
u = urllib2.urlopen(url)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 154, in urlopen
return opener.open(url, data, timeout)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 437, in open
response = meth(req, response)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 550, in http_response
'http', request, response, code, msg, hdrs)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 475, in error
return self._call_chain(_args)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 409, in _call_chain
result = func(*args)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 558, in http_error_default
raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 410: Gone

Seems the flex tar is gone from the source page (http://fossies.org/linux/misc/old/index_a.html). Maybe it's temporary, maybe not. To fix it, I've patched it locally by replacing the line 25 and 26 with:

'http://downloads.sourceforge.net/project/flex/flex-2.6.0.tar.bz2',

and later in code, line 597 with:

flex='flex-2.6.0',

Seems the build works ok now. Thanks a bunch for this repository, great work!

Unable to compile toolchain on Mac OS X El Capitan

I am unable to compile the toolchain on Mac OS X El Capitan. I was able to just a couple of weeks ago, but now it breaks when trying to compile the dummy for some reason! It could be related to a Xcode upgrade I installed recently.

cp xgcc gcc-cross /tmp/amigaos-cross-toolchain/.build-m68k/build/gcc-2.95.3/gcc/xgcc -B/tmp/amigaos-cross-toolchain/.build-m68k/build/gcc-2.95.3/gcc/ -B/usr/local/amiga/m68k-amigaos/m68k-amigaos/bin/ -I/usr/local/amiga/m68k-amigaos/m68k-amigaos/include -dumpspecs > tmp-specs mv tmp-specs specs touch stmp-headers echo "void __foo () {}" > dummy.c /tmp/amigaos-cross-toolchain/.build-m68k/build/gcc-2.95.3/gcc/xgcc -B/tmp/amigaos-cross-toolchain/.build-m68k/build/gcc-2.95.3/gcc/ -B/usr/local/amiga/m68k-amigaos/m68k-amigaos/bin/ -I/usr/local/amiga/m68k-amigaos/m68k-amigaos/include -DCROSS_COMPILE -DIN_GCC -g -I./include -c dummy.c m68k-amigaos-ar rc libgcc1.null dummy.o make[1]: *** [libgcc1.null] Abort trap: 6 make[1]: *** Deleting filelibgcc1.null'
make: *** [all-gcc] Error 2
ERROR: command "make all-gcc CFLAGS_FOR_TARGET=-noixemul MAKEINFO=makeinfo" failed with 2`

clang version:
$ clang -v Apple LLVM version 7.3.0 (clang-703.0.29) Target: x86_64-apple-darwin15.4.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

iostream example crashes

"make hello-iostream" works and builds hello-iostream. However, it crashes on start with 80000008. It seems that an std cout does not work. Other things from std seems to work. Additionally it works if I just compile anything with cout and link it using the native g++ under OS 3. So, it is something related to the linker when cout is used.

Additionally, executed in the examples folder:

$ make
m68k-amigaos-gcc -noixemul -s -fbaserel -Os -Wall -fomit-frame-pointer -m68000 -msmall-code hello-ks13.c -lnix13 -o hello-ks13
collect2: ld terminated with signal 6 [Abort trap: 6], core dumped
pc relative relocation out of range in section.text. Relocation was to symbol __edata
make: *** [hello-ks13] Error 1

stdio functions from libnix not usable on Kickstart 1.3

I wish to write a program for my real Amiga 500 with kickstart 1.3 using the toolchain. My program needs 'printf' and 'sprintf'.

Tried hello.c from the examples directory; the A500 complained about a missing library version 37 and nothing got printed on screen.

hello-ks13.c worked fine, got the hello world string.

If I take hello-ks13.c and include stdio.h and try to sprintf something somewhere in my program, the A500 crashes badly with: Software error task held, Finnish ALL disk activity etc…
Tried this with
-noixemul
-noixemul -lnix13
-noixemul -fbaserel -m68000 -msmall-code -lnix13

ndk/include/inline/layers.h missing LayerOccluded(), HideLayer(), ShowLayer(), SetLayerInfoBounds()

When compiling certain projects here I identified certain function inline to be missing in the NDK headers (inline/layers.h) your toolchain provides:

0xDE - LayerOccluded()
0xE4 - HideLayer()
0xEA - ShowLayer()
0xF0 - SetLayerInfoBounds()

Can you please add these functions to the corresponding fd/sfd file and update the layers.h inline header file?

file:// or some equivalent of url support

I'd like to use local hard-disk-stored source files in some cases. (My particular case is that I intend to use the gcc-2.95.4-prerelease version.) For that, support for file:///home/me/xxx.tar.gz type URLs, or some equivalent of it, would be very welcome.

bfd does not recognize amiga hunk format anymore

strip seems to be broken with the latest git checkouts:

$ m68k-amigaos-strip -S hello-stdio
m68k-amigaos-strip: hello-stdio: File format not recognized

binutils-2.26: rewrite of AmigaHunk support for BFD

AmigaHunk support for binutils hadn't been ever finished by it's previous maintainers. Current feature set of GNU binutils is limited - the tools:

• don't use AmigaHunk format for object files,
• use AT&T assembly syntax instead of Motorola syntax,
• data / bss chip sections cannot be represented in modified a.out format,
• cannot create AmigaHunk link libraries,
• ... and other less used features are probably missing.

To make things worse, current AmigaHunk support for BFD:

• crashes time to time without good reason,
• cannot be compiled on 64-bit architecture due to protability issues,
• is written in a way that makes it extremely difficult to update it to more recent versions of binutils.

Without more recent version of GNU as and GNU ld there's little sense in updating gcc (which switched to Motorola assembly syntax in later versions) and libnix (because it is missing support for C99 and C11). Also GNU gdb relies heavily on BFD support. Thus I find rewrite AmigaHunk support for BFD necessary to make any progress with whole toolchain as such.

AmigaHunk format is comprehensively described in:

• The Amiga Guru Book, chapter 22
• The AmigaDOS Manual (3rd edition), chapter 10

I implemented Python tools to read a.out format and AmigaHunk format. One could use them for reference as well.

GNU binutils are described in several documents:

• Binutils Porting Guide To A New Target Architecture
• GNU as
• AS Internals
• GNU bfd
• BFD Internals
• GNU ld
• LD Internals

gcc-2.95.3: Internal compiler error in `instantiate_virtual_regs_1', at function.c:3885

Why trying to compile the latest amisslv4 sources (https://github.com/jens-maus/amissl/tree/master) using yours (and other existing) gcc-2.95.3 based cross compilers I run into the following issue:

[...]
m68k-amigaos-gcc -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSLDIR="\"AmiSSL:\"" -DENGINESDIR="\"AmiSSL:engines\"" -m68020-60 -msoft-float -DNO_INLINE_VARARGS -D__NO_NET_API -DB_ENDIAN -DOPENSSL_SYS_AMIGA -D__amigaos3__ -DOPENSSL_NO_STDIO -I../../include -I../../include/netinclude -W -Wall -O0 -g -gstabs -DBN_DEBUG -DCONF_DEBUG -DDEBUG  -resident32 -DAMISSL_COMPILE -I../../libcmt/include  -Iinclude -I../../openssl -I../../openssl/crypto/include -I../../openssl/include -Icrypto/include -c -o crypto/bn/bn_nist.o ../../openssl/crypto/bn/bn_nist.c
../../openssl/crypto/bn/bn_nist.c: In function `BN_nist_mod_192':
../../openssl/crypto/bn/bn_nist.c:491: Internal compiler error in `instantiate_virtual_regs_1', at function.c:3885
Please submit a full bug report.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

Compiling with anything higher than -O0 (e.g. -O1) already worksaround this problem.

After investigation I found the following gcc bugzilla entry reporting on a similar issue with GCC 2.95.3 and m68k builds:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8343

This resource suggests the following patch to be applied:

--- gcc-2.95.3/gcc/config/m68k/m68k.md
+++ gcc-2.95.3/gcc/config/m68k/m68k.md
@@ -3062,7 +3062,7 @@
   [(parallel
     [(set (subreg:SI (match_operand:DI 0 "register_operand" "") 1)
    (mult:SI (match_operand:SI 1 "register_operand" "")
-      (match_operand:SI 2 "nonimmediate_operand" "")))
+      (match_operand:SI 2 "register_operand" "")))
      (set (subreg:SI (match_dup 0) 0)
    (truncate:SI (lshiftrt:DI (mult:DI (zero_extend:DI (match_dup 1))
               (zero_extend:DI (match_dup 2)))
@@ -3101,7 +3101,7 @@
   [(parallel
     [(set (subreg:SI (match_operand:DI 0 "register_operand" "") 1)
    (mult:SI (match_operand:SI 1 "register_operand" "")
-      (match_operand:SI 2 "nonimmediate_operand" "")))
+      (match_operand:SI 2 "register_operand" "")))
      (set (subreg:SI (match_dup 0) 0)
    (truncate:SI (lshiftrt:DI (mult:DI (sign_extend:DI (match_dup 1))
               (sign_extend:DI (match_dup 2)))

After having added that match to the patches/gcc-2.95.3/gcc/config/m68k/m68k.md.diff file in your repository the problem still exists and prevents from building a nice debug build of the latest AmiSSL developer build.

I might be missing something here as I can't see that the gcc binary actually changed at all with the patch applied?!? Any help appreciated.

./toolchain-ppc does not build

I try to compile with:
# ./toolchain-ppc --prefix=/opt/ppc-amigaos build
/opt directory is writable by user

...on Ubuntu 14.04 LTS (32bit) with:
gcc v5.4.1
make v4.2
python v2.7.6
python-dev v2.7.5
perl v5.22.2
libncurses5-dev v5.9
git v1.9.1
patch v2.7.1
gperf v3.0.4
bison v3.0.2
svn v1.8.8
flex v2.5.35

Compile script stops with these final lines:

...
A    gcc-4.9.1/install-sh
A    gcc-4.9.1/ylwrap
 U   gcc-4.9.1
Checked out revision 629.
Traceback (most recent call last):
  File "./toolchain-ppc", line 231, in <module>
    globals()[action].__call__(*args.args)
  File "./toolchain-ppc", line 82, in build
    unpack('python-lha', work_dir='{build}')
  File "/home/alper/Genel/AmigaDev/amigaos-cross-toolchain/common.py", line 37, in wrapper
    return fn(*args, **kwargs)
  File "/home/alper/Genel/AmigaDev/amigaos-cross-toolchain/common.py", line 357, in wrapper
    fn(*args, **kwargs)
  File "/home/alper/Genel/AmigaDev/amigaos-cross-toolchain/common.py", line 404, in unpack
    glob(path.join('{submodules}', name) + '*'))[0]
  File "/home/alper/Genel/AmigaDev/amigaos-cross-toolchain/common.py", line 35, in wrapper
    args = list(fill_in(arg) for arg in args)
  File "/home/alper/Genel/AmigaDev/amigaos-cross-toolchain/common.py", line 35, in <genexpr>
    args = list(fill_in(arg) for arg in args)
  File "/home/alper/Genel/AmigaDev/amigaos-cross-toolchain/common.py", line 29, in fill_in
    return value.format(**VARS)
KeyError: 'submodules'

Thanks in advance.

Preprocessor uses libnix header files when no CRT library is specified

Without -noixemul or -mcrt=* preprocessor should fail to find stdlib.h, because the header file is a part of standard C library (either nix or clib2). Following example should fail:

$ cat 0.c
#include <stdlib.h>
#include <stddef.h>
$ PATH=/opt/m68k-amigaos/bin:$PATH m68k-amigaos-gcc -c 0.c

Conclusion: $PREFIX/m68k-amigaos/sys-include should be dropped!

Toolchain compile Error using newest Cygwin 2.874 (32 bit)

I get an error when building the toolchain under cygwin 2.874 (32 bit).

Attached the console output.

output.txt

vc.config created with bad permissions

{prefix}/etc/vc.config is copied without group and world read permissions,
i.e. 0600 instead of 0644. If the toolchain is created with root user, say
under /opt/m68k-amigaos/, the config file isn't readable by ordinary users
and vc fails with "no config" error, unless the permissions are corrected
manually.

vasm script calls vasmm68k_mot in wrong path

a tiny typo: vasmm68k_motis located in {prefix}/{target}/bin(bin is missing)
TIA!

Please add obj-c to the list of cross-compiled languages

I am using a build of 2.95.3 on the Amiga that has Objective-C present. This one doesn't provide that. I am close to getting it to work and if I do I will put out a pull request with the changes, but it would be nice to have more than less if possible.

ld: cannot open crt0.o: No such file or directory

Let me start with a big "Thank you!" for providing this toolchain. I recently dusted off my Amiga 1200 and now want to get my feet wet with cross-compiling for AmigaOS.

I made a fresh installation of Fedora 21 32bit in a virtual machine and followed the instructions in README.md (see #11 for what was missing from it for me).

I then used the following "Hello world!" example code to test the cross-compiling toolchain ...

#include <stdio.h>
int main()
{
    printf("Hello World!\n");
    return(0);
}

... with this command to invoke the cross-compiler

$ m68k-amigaos-gcc hello.c -o hello
/usr/local/m68k-amigaos/m68k-amigaos/bin/ld: cannot open crt0.o: No such file or directory
collect2: ld returned 1 exit status

What am I missing? Compiling with -noixemul works:

$ m68k-amigaos-gcc hello.c -o hello -noixemul

The binary generated by the command above executes properly on my Amiga 1200 with AmigaOS 3.9.