Setting up an Amiga Cross-Compiler (Windows) part 1 (original) (raw)

This is the Windows version, if you are running Linux or MacOS X, please check my other post about them here.

VBCC is an excellent compiler, still actively developed and supports multiple target platforms, including our favorite Amiga (and clones). While the procedure to get it installed on Linux/Mac is rather straightforward (you have to download the sources, then compile them), it can be a bit more tricky if you are on Windows. This post is meant to help with that, guiding through all the steps necessary to get your environment up and running with the minimum hassle.

The quick and easy approach

Since other people have gone through the same pain, it should be expected that someone has thought about simplifying the procedure and providing some shortcuts. There are now 2 different “easy” approaches (choose one):

1. A Windows Installer package, by Leffmann: http://eab.abime.net/showthread.php?t=83113
2. Erik Faye-Lund has created a package containing the latest pre-compiled binaries, along with the target platform and even the NDK and PosixLib packages included.

The steps to install this package are as follows:

1. Head over to Github and download the package.
2. Extract/install everything to “C:\amiga-dev\”.
3. Add “C:\amiga-dev\bin\” to the system PATH environment variable.
4. Set the “VBCC” environment variable to “C:\amiga-dev\targets\m68k-amigaos”.

Quite simple and straightforward, don’t you think?

Although the above “just works”, you can have more nerdy fun if you choose to compile everything from source yourself, potentially learning something along the way. If you are such a person, read on to the Advanced section below. Otherwise, you’re already good to go – write some code and experiment!

The advanced nerd approach

Some people like it easy. Some people prefer to go through the steps manually and fine-tune, learn and achieve that extra level of accomplishment once they get it to work. If you’re one of those people, this section is for you. 🙂

Requirements

• A Windows compiler: Since we’ll be compiling the sources, we will need a compiler in our system. The recommended one is Visual Studio 2013 (even the free Community Edition is enough) or higher (tested up to VS 2017). It may work with older/newer versions as well of course, or even with other compilers – but you’ll have to experiment a bit on your own with that.
• Windows SDK: the compiler will need some common C libraries to do it’s work on the sources, so we’ll need those. You can get the latest one for Windows 10 from here, but other versions should work as well.
• An archiving tool that is able to decompress *.tar.gz files. I recommend 7-zip.
• Your favorite text editor: Although Notepad will also work, I recommend the excellent Notepad++.

Once you’ve got the above installed and/or updated, it’s time to start having fun. Follow these steps:

VBCC

First of all, we need to download the sources package. You can get the current snapshot archive from here. If you want to read more information about it, you can visit the official website: http://www.compilers.de/vbcc.html

Extract the archive somewhere, e.g. to

C:\vbcc

Next comes our first challenge. The included Makefile will not work out-of-the-box on Windows, since it was designed for Linux/Mac platforms originally, using the GCC compiler. There are things in there that need to change before we can use it, such as paths using forward slashes (“/”) which Windows does not understand and instead expects with backslashes (“\”).

For your convenience, here’s a modified Makefile including all the changes below. If you prefer to do it manually regardless, read on. Otherwise, skip to the next section – Compiling VBCC.

Open the Makefile with your Text Editor, save a copy of it with a new name (e.g. “MakefileVS.mak”) and make the following changes in it:

• Replace all forward slashes (“/”) to backslashes (“\”).
• Replace the second line from this:

CC = gcc -std=c9x -g -DHAVE_AOS4 #-DHAVE_ECPP -DHAVE_MISRA

To this:

CC = cl /D_CRT_SECURE_NO_WARNINGS /nologo /O2 /MT /Zp1 /wd4715 /wd4068 /wd4048

• Remove the parameter in the LDFLAGS line, so from this:

LDFLAGS = -lm

it should now read:

LDFLAGS =

• Find and replace all occurrences of “-o ” (notice the extra space after “-o”) with “/Fo”, only if they are preceding a file name ending with “.o”. In other words, something like this:

-o $(TRGDIR)/mbasic.o

should be replaced with this:

/Fo$(TRGDIR)/mbasic.o

but something like this should not be replaced (yet), since it does not specify a file name ending with “.o”:

-o bin/vc $(LDFLAGS)

• Now we can replace the remaining “-o ” (again, notice the extra space) entries with

“/link /NOLOGO /OUT:”

So for example, this line:

(CC)frontend/vc.c−obin/vc(CC) frontend/vc.c -o bin/vc (CC)frontend/vc.c−obin/vc(LDFLAGS)

should be replaced with this:

(CC)frontendvc.c/link/NOLOGO/OUT:binvc(CC) frontend\vc.c /link /NOLOGO /OUT:bin\vc (CC)frontendvc.c/link/NOLOGO/OUT:binvc(LDFLAGS)

• Add “.exe” to the output executable files, in the lines affected on the previous step. For example, the above line:

(CC)frontendvc.c/link/NOLOGO/OUT:binvc(CC) frontend\vc.c /link /NOLOGO /OUT:bin\vc (CC)frontendvc.c/link/NOLOGO/OUT:binvc(LDFLAGS)

should be amended like this:

(CC)frontendvc.c/link/NOLOGO/OUT:binvc.exe(CC) frontend\vc.c /link /NOLOGO /OUT:bin\vc.exe (CC)frontendvc.c/link/NOLOGO/OUT:binvc.exe(LDFLAGS)

• Replace all “-c” occurrences into “/c”.
• Replace all “-I” occurrences into “/I”.
• Replace all “-D” occurrences into “/D”.
• Remove the “/Idatatypes” keyword from the below line:

bin\dtgen: datatypes\dtgen.c datatypes\datatypes.h datatypes\dtconv.h
(NCC)datatypesdtgen.c/link/NOLOGO/OUT:bindtgen.exe  /Idatatypes  (NCC) datatypes\dtgen.c /link /NOLOGO /OUT:bin\dtgen.exe /Idatatypes (NCC)datatypesdtgen.c/link/NOLOGO/OUT:bindtgen.exe  /Idatatypes  (NLDFLAGS)

• Replace all “.o” occurrences into “.obj”. Not absolutely necessary, but will save us some warnings during compilation.
• Finally, you can optionally remove (or comment out) sections that are unused on Windows, such as:
  • doc/*
  • vcppobjs
  • vbcc.tar.gz:
  • dist: bin\osekrm
  • bin\vcpp:
  • vcpp/*
  • the last section starting with the comment “# Graph coloring register allocator by Alex” until the end of the file.

Compiling VBCC

Now that the hard part is over, we can finally try to compile VBCC. Follow these steps to do so:

• Open the VBCC directory (e.g. C:\vbcc)
• Create a new directory named “bin”. That’s where the compiled executables will end up.
• Start a “Developer Command Prompt for VS20xx” from your Start menu (it’s found under Visual Studio Tools), and navigate to the VBCC directory (e.g. “CD \vbcc”).
• Type the following command to compile “vc.exe”:

nmake /f MakefileVS bin\vc

• Type the following command to compile “vbccm68k.exe”:

nmake /f MakefileVS TARGET=m68k bin\vbccm68k

• Answer the questions as follows (you can just press enter for the default answer also):
  • Are you building a cross-compiler? – y
  • Does your system/compiler support a type implemented as standard 2-complement 8bit byte? – y
  • Enter that type[signed char]: – signed char
  • Does your system/compiler support a type implemented as standard unsigned 8bit byte? – y
  • Enter that type[unsigned char]: – unsigned char
  • Does your system/compiler support a type implemented as standard 8bit-byte-based 2-complement 16bit word, big-endian? – n
  • Does your system/compiler support a type implemented as standard 8bit-byte-based 2-complement 16bit word, little-endian? – y
  • Enter that type[]: signed short
  • Does your system/compiler support a type implemented as standard 8bit-byte-based unsigned 16bit word, big-endian? – n
  • Does your system/compiler support a type implemented as standard 8bit-byte-based unsigned 16bit word, little-endian? – y
  • Enter that type[]: unsigned short
  • Does your system/compiler support a type implemented as standard 8bit-byte-based 2-complement 32bit word, big-endian? – n
  • Does your system/compiler support a type implemented as standard 8bit-byte-based 2-complement 32bit word, little-endian? – y
  • Enter that type[]: signed int
  • Does your system/compiler support a type implemented as standard 8bit-byte-based unsigned 32bit word, big-endian? – n
  • Does your system/compiler support a type implemented as standard 8bit-byte-based unsigned 32bit word, little-endian? – y
  • Enter that type[]: unsigned int
  • Does your system/compiler support a type implemented as standard 8bit-byte-based 2-complement 64bit word, big-endian? – n
  • Does your system/compiler support a type implemented as standard 8bit-byte-based 2-complement 64bit word, little-endian? – y
  • Enter that type[]: signed long long
  • Does your system/compiler support a type implemented as standard 8bit-byte-based unsigned 64bit word, big-endian? – n
  • Does your system/compiler support a type implemented as standard 8bit-byte-based unsigned 64bit word, little-endian? – y
  • Enter that type[]: unsigned long long
  • Does your system/compiler support a type implemented as standard 8bit-byte-based 32bit IEEE floating-point, big-endian? – n
  • Does your system/compiler support a type implemented as standard 8bit-byte-based 32bit IEEE floating-point, little-endian? – y
  • Enter that type[float]: float
  • Does your system/compiler support a type implemented as standard 8bit-byte-based 64bit IEEE floating-point, big-endian? – n
  • Does your system/compiler support a type implemented as standard 8bit-byte-based 64bit IEEE floating-point, little-endian? – y
  • Enter that type[double]: double

If all goes well, you should see a list of messages scroll by (but no errors) and finally the operation completes successfully, resulting in the executable files in the “bin” directory. Pat yourself in the back, we’ve been through the most difficult part. 🙂

In the next post, we’ll prepare and compile VLINK and VASM as well, after which we’ll have all the pieces together. Then we need to setup our environment and configure some Target platforms, before we can create our fist program.