[Updated 2017-10-17 -- Minor corrections to the list of Cygwin/Uwin installed packages and Cygwin/Uwin PATH variables and an Amiga-specific test executable. Also various minor typo and content changes to reflect various posters' replies to this originating post.]

Given the nature of Cygwin64/UWin x64, these instructions will also all probably work really well on x86/x64/PPC Linux/Mac environments with GCC5.x -- with only minor changes (haven't tried them, though, so if anyone wants to try, please do and let us know how it goes!).

As always, these tips are provided as-is, at your own risk, but please run as little as you can as sudo/root!

So. Why this post?

Hopefully, this can save someone else a ton of irritating time waste just to get a full/proper development environment on Cygwin/Windows to set up a GCC 5.x cross-compiler tool chain that produces AmigaOS/OS4 Final Edition binaries for amigaos on PowerPC/ppc.

By saving developers massive amounts of time to just get their cross-compiling environment to kick out an OS4 "Hello World", and updating other instructions out there that are obsolete by several _years_, and by yielding a fantastic toolchain for a very modern Cygwin or UWin developer environment; I'm hoping this will help reduce one major barrier to keeping/attracting developers to the Amiga world.

I'm targeting both Cygwin GCC and UWin GCC as the Windows-based cross-compiling hosts of choice in this post. I may eventually add MingW/GCC instructions as well -- nothing against MingW, just haven't gotten around to testing/trying. Anyone reading this is more than welcome to try all these instructions on MingW/GCC and let all of us know your experience.

[Note: This post is annotated a bit more verbosely so it's easier for search engines to find. And, yes, that's a ridiculous title, because Microsoft hasn't chosen a single brand name for their Linux on Windows environment -- it goes by (too) many names. Lastly, yes, this is a very long post -- I've made it very detailed and self-contained by design.]

Cygwin64 adtools native / cross-compile build from source/scratch

For a _lot_ of reasons, I've long been a very big fan of Cygwin. That team has built/continues to make an amazingly well-thought-out/well-supported POSIX environment/GNU ecosystem on Windows.

[In case you're wondering or have tinkered like me, I even still prefer the rock-solid/very mature Cygwin (by a lot) to the very new/alpha-quality Linux subystem for Windows (bash-on-ubuntu-on-windows). Cygwin's penalty of source-only compatibility with Linux vs. the new Linux subsystem's binary compatibility with Ubuntu Linux just isn't that big of a deal for me -- especially when one considers the monstrous libary of binary packages maintained by Cygwin's community. No matter what, you either have to install a binary package (cygwin vs. debian/ubuntu package) or build from source. Given that source is (thankfully) available for about 99.999% of what I need in my Cygwin/Linux environments, binary-compatibility of the linux-subsystem is basically a moot point.]

Anyways, I set-out to do a simple thing. Get a tool chain working, either natively inside an emulated OS4 environment on my Win10 Pro machine (a really inexpensive and easy OS4 emulator setup if you buy all of Amiga Forever 7/Amikit X+FlowerPot/OS4.1FE for Classics and follow the FlowerPot instructions); or do a cross-compile tool chain in the Cygwin subsystem on that same machine and test/deploy inside that emulated OS4 environment.

Turns out, it was a really big pain.

I tried everything I could read/think of to get the cross-compile and native tool chains to work. Read all the instructions. Had no joy with even native/plain-jane SDK 53 from Hyperion inside the OS4 emulator. Got lots of things/gcc chains installed -- but Hello World kept crashing???

I got irritated with the native tools, and so I tried all the pre-built cross-compile toolchains I could find. All crashed/failed to build something. Or were out of date. The toolchain builders found on github or elsewhere were fragile/unreliable/didn't work. Most of the binary archives I could find were _not_ for GCC 5, nor for Cygwin, nor for UWin.

I even tried using various Linux-native pre-built binaries on bash-on-ubuntu-on-Windows. No go.

Finally, I just simply decided build everything from scratch: but I wanted a Cygwin and/or UWin hosted PPC cross-compiler. The following probably works for Cygwin32, Linux, and Mac, with appropriate modifications, but I didn't try.

Note, I'm targeting the full Cygwin environment, not Ming or other; and I'm targeting the gcc toolchain including g++, not VBCC, because I want the full GNU toolchain.

Cygwin Steps:

Install Cygwin64 (not sure if this works with Cygwin32, probably does, given that we're not trying to cross compile into a 64-bit OS4 environment -- if you try Cygwin32 you'll probably want to rename all references here from "Cygwin64" or "cyg64" to "Cygwin32" or "cyg32", respectively, to avoid confusion).

TIP: Don't use spaces in any directory names or filenames throughout this entire environment. That includes the Cygwin installation directory!

Most of these were auto-installed. Not sure even how many are strictly necessary.

As of this writing, the gcc-core/gcc-g++ packages were version 6.4.0-1

You'll almost certainly have to reboot after all the Cygwin installations.

The really tricky part -- getting lhasa on Cygwin, not so easy to find; so, in Cygwin, after you've installed all the above packages and rebooted, download and build from scratch the latest lhasa source package you can find.

Note these instructions, as written, are version-specific to the adtools release because it's a good idea to have version-specific instructions to allow current and future versions of the tools to co-exist on the same machine.

Take that path just shown above. You'll want to edit that command to use the version number of the adtools source package you're using, as at the time of your build. More on this below.

While this step is optional, do it to save your sanity: by using the symlink above, you can keep compiling-from-source the toolchain whenever new releases are issued and then re-create this symlink to point to the latest version -- without hardcoding that version into your path and screwing yourself up for all subsequent uses of the toolchain. The path shown below, for example, assumes you're pointing the adtools symlink to the desired/correct version of the adtools directory. Subsequent uses of this symlink will also be very much assisted -- like in makefiles which shouldn't be hard-coded to the adtools version you're using.

export PATH=$PATH:~/adtools/bin:/usr/local/amiga/adtools/bin

(You probably want to use "nano /etc/profile" to add that export command to the end of your /etc/profile file so every boot/new shell will keep the path for you.)

Then, skip down to common instructions below...

Bash on Ubuntu on Windows ("UWin") Steps:

Note, you _require_ at least Windows 10 Creators Update and its associated Linux Subsystem for Windows/bash-on-Ubuntu-on-Windows/Ubuntu on Windows/Linux Subsystem/Windows Subsystem for Linux/Linux on Windows feature installed. This will _not_ work with earlier versions!

TIP: Don't use spaces in any directory names or filenames throughout this entire environment!

Note these instructions, as written, are version-specific to the adtools release because it's a good idea to have version-specific instructions to allow current and future versions of the tools to co-exist on the same machine.

Take that path just shown above. You'll want to edit that command to use the version number of the adtools source package you're using, as at the time of your build. More on this below.

While this step is optional, do it to save your sanity: by using the symlink above, you can keep compiling-from-source the toolchain whenever new releases are issued and then re-create this symlink to point to the latest version -- without hardcoding that version into your path and screwing yourself up for all subsequent uses of the toolchain. The path shown below, for example, assumes you're pointing the adtools symlink to the desired/correct version of the adtools directory. Subsequent uses of this symlink will also be very much assisted -- like in makefiles which shouldn't be hard-coded to the adtools version you're using.

export PATH=$PATH:~/adtools/bin:/usr/local/amiga/adtools/bin

(You probably want to use "nano ~/.bashrc" to add that export command to the end of your bashrc file so every boot/new shell will keep the path for you.)

If, from your home directory or ~/adtools, running "gcc -v" and also "g++ -v" shows a bunch of output whose text includes "x86_64-linux-gnu" and "gcc version 5.4.1" then you don't need the symlinks below. Otherwise, like me, the package for gcc5 on your version of UWin doesn't want to clobber the gcc4 commands (even if you don't have gcc4 installed).

If "gcc-v" or "g++ -v" throws an error, you need to create some symlinks...

Read very carefully the instructions at https://github.com/sba1/adtools. In particular, take a careful read of the "Patch management" and "Building" instructions.

[Note: As of this writing, the adtools git repository is for the 20170623-404 build. FYI -- This is the exact same version of the adtools package of all the binary adtools packages I could find; and they installed just fine in the OS4 environment, but they would create "Hello World" executables that just crashed. I couldn't find any binary cross-compiler packages of this version. That's the great benefit of following the method shown in this guide -- the latest possible version of the adtools toolchain for your cross-compiler Cyg/UWin environment of choice.]

gild checkout binutils 2.23.2 (you may get an error on first gild checkout command, as the git server might insist on your git account/name information to check out source -- just follow the gild/git command's instructions to fix that then re-run the "gild checkout binutils..." command.)

make -C native-build gcc-cross CROSS_PREFIX=/usr/local/amiga/adtools-ppc-cyg64-20170623-404 (also takes quite a bit of time to run, as it'll build your native toolchain and also the cross-compiler chain).

(Remember to edit that CROSS_PREFIX directory name to the actual version of the adtools release you're building. And then make sure the "adtools" symlink described above which is supposed to point to the actual adtools directory actually points to the right directory name. The exact version/directory name used here is only an example based on the version I used at the time of this writing, and as you build the adtools package over time, you'll need to keep updating the CROSS_PREFIX directory name AND the "/usr/local/amiga/adtools" symlink that points to it so you can use newer versions (or revert to older ones doing the opposite) over time).

For UWin:

make -C native-build gcc-cross CROSS_PREFIX=/usr/local/amiga/adtools-ppc-uwin64-20170623-404 (also takes quite a bit of time to run, as it'll build your native toolchain and also the cross-compiler chain).

(Remember to edit that CROSS_PREFIX directory name to the actual version of the adtools release you're building. And then make sure the "adtools" symlink described above which is supposed to point to the actual adtools directory actually points to the right directory name. The exact version/directory name used here is only an example based on the version I used at the time of this writing, and as you build the adtools package over time, you'll need to keep updating the CROSS_PREFIX directory name AND the "/usr/local/amiga/adtools" symlink that points to it so you can use newer versions (or revert to older ones doing the opposite) over time).

For both Cygwin and UWin:

Now, assuming you have no errors in that big build task and everything else above, check that everything's working:

cd ~ppc-amigaos-gcc -v

Should show you a bunch of output, most importantly, it should say "Target: ppc-amigaos" and "gcc version 5.4.0 (adtools build 5.4.0)"

Assuming you saved that "hello.c" file in your ~/adtools directory, do the following:

cd ~/adtoolsppc-amigaos-gcc -o hello hello.c

Which creates the "hello" executable, which you then need to copy-to/access-from your OS4 (or in my case, emulated-OS4) environment to test the newly-created hello executable in an OS4 command shell.

Similarly, use "nano ~/adtools/hello.cpp" to create/test a c++ source file with the following:

#include <iostream>using std::cout;using std::endl;

int main(){ std::cout << "Hello cross-compiled c++ World!" << endl;}

Assuming you saved that "hello.cpp" file in your ~/adtools directory, do the following:

cd ~/adtoolsppc-amigaos-g++ -o hellocpp hello.cpp

Which creates the "hellocpp" executable, which you then need to copy-to/access-from your OS4 (or in my case, emulated-OS4) environment for testing in an OS4 command shell.

For me, this moving of OS4 executables into the OS4 environment is nearly trivial as the fantastic FlowerPot-built OS4.1 emulated setup gives easy access to my Windows drives so I've mapped my "Work:" assign to my windows/Cygwin user/home directory where all this took place. I don't actually have to "move" anything, I just directly access files thanks to the Win-UAE host drive/directory mapping set up by FlowerPot when it installed the whole OS4 kit from scratch.

An Amiga-Specific Test

If you can successfully run the above "hello" and "hellocpp" executables in your OS4 environment, then it's time to do one more thing, to ensure your cross-compiling setup is set-up so that all the Amiga OS4 libs/headers are accessible to the cross-compilers. Otherwise, you won't be getting very far!

Let's create "easy" another OS4 executable, but one that does a lot more than Hello, World. This one calls the AmigaOS 4 Intuition C library; and is a good test of the build environment's ability to build true AmigaOS 4 binaries.

Again, from your home directory on Cygwin or UWin:

"nano easy.c"

Then copy/paste the following into your nano editor. Then save/exit nano.

/* easy.c: a complete example of how to open an Amiga function library in C. * In this case the function library is Intuition. Once the Intuition * function library is open and the interface obtains, any Intuition function * can be called. This example uses the DisplayBeep() function of Intuition to * flash the screen. */

if(IIntuition != NULL) /* Check to see if it actually opened. */ { /* The Intuition library is now open so */ IIntuition->DisplayBeep(0); /* any of its functions may be used. */ }

// Always drop the interface and close the library if not in use. // Note it is safe to call DropInterface() and CloseLibrary() with NULL pointers. IExec->DropInterface((struct Interface *)IIntuition); IExec->CloseLibrary(IntuitionBase);}

When you return to your Cygwin/Uwin command-line:

ppc-amigaos-gcc -o easy easy.c

Within seconds, this should create the executable "easy". Go ahead and try running the "easy" executable in a command shell in your Amiga/OS4 environment. "easy" should simply flash the Workbench screen title. If it does that, fantastic.

What's Next?

If all of the above works, you're done, and you have a fully functioning Cygwin-hosted or bash-on-Ubuntu-on-Windows-hosted, gcc & g++ 5.x cross-compiling toolchain for Amiga OS4.

Note, all of the above was (intentionally) set out to describe how to create a Windows-hosted command-line gcc-based cross-compiling toolchain to target OS4. I deliberately make no mention of IDE choice/integration here, as that's about as individual as it gets.

Lastly, as new adtools versions get released: remember to re-read these instructions and keep in mind with each new version of the adtools source package, to edit/update my instructions using the right version number for the CROSS_PREFIX value and the "adtools" symlink.

Edited by stonecracker on 2017/10/5 11:34:56Edited by stonecracker on 2017/10/5 11:39:25Edited by stonecracker on 2017/10/5 11:41:10Edited by stonecracker on 2017/10/5 11:45:51Edited by stonecracker on 2017/10/6 12:35:06Edited by stonecracker on 2017/10/6 22:06:24Edited by stonecracker on 2017/10/7 20:24:15Edited by stonecracker on 2017/10/8 8:11:07Edited by stonecracker on 2017/10/18 5:12:47Edited by stonecracker on 2017/10/18 5:21:36Edited by stonecracker on 2017/10/18 5:25:37Edited by stonecracker on 2017/10/18 5:28:36Edited by stonecracker on 2017/10/19 14:18:35Edited by stonecracker on 2017/10/21 22:14:37Edited by stonecracker on 2018/2/27 20:52:14

Yes, Ubuntu-on-Win/UWin/Windows Subsystem for Linux/Linux Subsystem/LXSS/Bash-on-Ubuntu-for-Windows, are all names for the same thing. Microsoft clearly hasn't settled on the branding of this!

Please, if you have some spare time, feel free to get the UWin stuff working. It makes for MUCH easier IDE integration from a Windows IDE, like Visual Studio (or really any IDE) -- but really, aside from IDE integration there's almost nothing that Cygwin can't do for this (and many, many) other purposes.

I've actually uninstalled UWin on a couple of machines in favour of Cygwin. Much more stable.

It might be worth noting that I do _NOT_ have Creator's Edition of Windows 10 running; and that probably makes a difference with the UWin binaries.

The version of UWin I'm running is: Linux version 3.4.0-Microsoft (Microsoft@Microsoft.com) (gcc version 4.7 (GCC))

I'm pretty sure it's something to do with the Linux subsystem version I'm running; despite using the latest apt packages for my setup. As I noted in my original post -- all the build checks pass and a _ton_ of compiling/linking works until near the very end. With a bizarre error about the resulting cross-compiler being unable to compile an executable.

I can happily post my error details later on if desired. I'd be more interested in seeing how far you get with my instructions on a later version of UWin.

Thank you stonecracker for this. I will try to use this in my WIndows 10 laptop. I have a question for you.

Since i use SDL2 for some projects, how can i proceed to use sdl2 for Amiga or how could this work? Should i copy the entire Amiga OS4 SDK, containing the SDL2 libs? And what about the compiled AmigaOS4 SOBJ?

I had a chance to try and build it today under latest version of UWIN and unfortunately it still fails.

I think I understand the issue but not sure yet how to fix it. Looking at output the failure is when g++ invokes the assembler that has just been built. The newer versions of "g++" set the command line option of --64 to newly built "as" since it is a 64 bit environment. The version of "as" that is built does not support --64 and it kills the build.

I figured it out when it dawned on my it was running the newly built as as opposed to the correct version from distro. That extra ":" causes the current working directory to become part of path and as is in the directory when gcc is being built.

Fantastic! And thanks for figuring that out. I, personally, didn't have quite enough interest or time to push through that. I'm glad someone did.

I'll update my original post shortly, once I hear about any other cumulative error corrections anyone comes up with for both Cygwin and Uwin.

I confirmed what you did: the PATH setting is what screwed things up on Uwin. The PC I'm using to test all this out still can't download the Windows Creators Update which is a prerequisite (updated/later Ubuntu version) to making the UWin work.

Are you attempting the Cygwin or UWin instructions where you're running into the git problem; if Cygwin, is the git issue with the adtools or lhasa checkout?

With Cygwin. It's with the lhasa checkout (which also uses an HTTPS URL).

As stated earlier, I managed to get a step further by switching https with git in the URL. However, I then got stuck in the adtools instructions at "git submodule update" (for gild). That tries to fetch over https again...

@billyfish

Quote:

I've had that before if git has been compiled without access to libcurl (https://curl.haxx.se/libcurl/). If you install that then rebuild git you should be fine.

True, but why is the official Cygwin version compiled without libcurl? I tried reinstalling the git package after installing libcurl and it still didn't work.

I really shouldn't have to do a custom build just to get a fully working git.

This is why I've never bothered with cross-compiling; getting the cross-compiler set up has always failed for one reason or another with cryptic error messages. And yes, this is while following instructions provided by others.

I've updated my original post a bunch thanks to your various input/questions. Will start 2 new threads ASAP as alluded to at the end of my big post -- one on how to actually use the Cygwin/UWin cross-chain for 3rd party and new code; and another on how to use Visual Studio 2017 with this new cross-chain.

As noted above, I'm about to post another detailed post, but in a new thread, on how to actually use this cross-compiling toolchain with 3rd party or new codebases from the Cygwin/UWin command-line.

Additionally, I'm about to post yet another one on how to use Visual Studio 2017 with existing, new, and 3rd party code and the Cygwin cross toolchain. (Only the Cygwin adtools cross chain for now, as I don't actually have a working UWin to create the instructions from).

Those instructions are somewhat involved as well and are quite different from the command line instructions.

Both of my next posts should hopefully answer your (and of course anyone else's) questions entirely.

No idea. It's could also be due to me already having Cygwin installed and initially using an older version of the installer.

I've now hit the next glitch: the make failed because my home directory has a space in the name, and the makefile can't cope with that. Fixing that was easy, though, I just moved the adtools directory.

EDIT: And I now have a working cross-compiler! Thanks for the instructions.