Building Cross-Compiling adtools for Amiga OS4 PowerPC (ppc) with Cygwin/Bash on Ubuntu on Windows

Updated for 2017 -- HOW TO build an Amiga / OS4 32-bit gcc 5.x cross-compiler tool chain, from the "adtools" source repository, from within a Cygwin/Cygwin64 build environment, or from within a bash-on-Ubuntu-on-Windows aka Ubuntu on Windows (UWin) aka Linux Subsystem (LXSS) aka Windows Subsystem for Linux (WSL) aka Linux on Windows build environment -- on a Windows 10 64-bit PC.


[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.]

[Updated 2019-10-26 -- Note, there are 3 related posts here that cover cross-compiling for Amiga OS4 from Windows:

1) The post you're reading now, on how to build a Windows-hosted toolchain (http://www.amigans.net/modules/xforum ... hp?topic_id=7623&forum=25)

2) A post on how to use the toolchain built by this post from a Windows / cygwin command line (http://www.amigans.net/modules/xforum ... m=25&topic_id=7654&order=)

3) A post on how to use the toolchain built by this post inside Visual Studio for Windows (http://www.amigans.net/modules/xforum ... 9&forum=25&post_id=108233) ]



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!

Install latest Cygwin packages: bison, bzip2, cygport, cygutils-extra, cygwin32, cygwin32-binutils, cygwin32-gcc-core, cygwin32-gcc-g++, cygwin32-gettext, cygwin32-libbfd, cygwin32-libiconv, cygwin32-libtool, cygwin32-minizip, cygwin32-zlib, flex, flexdll, gcc-core, gcc-g++, git, git-gui, git-svn, hdf5, libarchive-devel, libarchive13, libbz2-devel, libbz2_1, libgcc1, libgmp-devel, libgmp10, libhdf5_10, libhdf5cpp_11, libhdf5cpp_12, libhdf5cpp_13, libhdf5cpp_14, libhdf5hl_10, libmpc-devel, libmpc3, libmpfr-devel, libmpfr4, libzzip-devel, libzzip0.13, lz4, lzip, make, nano, python2, python2-devel, python3, python3-devel, sharutils, svn-load, svn_load_dirs, unzip, zip

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.

Example, from your home directory in your Cygwin bash shell:

git clone https://github.com/fragglet/lhasa
cd lhasa
./autogen.sh
make
make install


Or, from your home directory in your Cygwin bash shell:

wget https://github.com/fragglet/lhasa/archive/v0.3.1.tar.gz
Unpack the source in /usr/src
cd lhasa-0.3.1
./autogen.sh
make
make install

Then:

ln -s /usr/local/amiga/adtools-ppc-cyg64-20170623-404 /usr/local/amiga/adtools

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!

Start a bash shell as your regular user, in your home directory.

Assuming you've set up your home directory/user in this environment:

sudo apt-get install bison bzip2 flex gcc g++ git git-svn libgmp-dev libmpc-dev libmpfr-dev lhasa make nano python3 python3-dev texinfo unzip zip

FYI As of this writing gcc-5/g++-5 for UWin is version 5.4.1.

Then:

sudo ln -s /usr/local/amiga/adtools-ppc-uwin64-20170623-404 /usr/local/amiga/adtools

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.)

sudo mkdir /usr/local/amiga
sudo chown <your-uwin-username>:users /usr/local/amiga
sudo chown <your-uwin-username>:users /usr/local/amiga/adtools

I had to do the following symlinks, too, you might not.

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...

sudo ln -s /usr/bin/gcc-5 /usr/bin/gcc
sudo ln -s /usr/bin/g++5 /usr/bin/g++


Then, skip down to common instructions below...



Common Instructions for both Cygwin and UWin:


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.]


Launch a bash shell (the default shell for both Cygwin and UWin).

From your home directory:

git clone https://github.com/sba1/adtools.git (which will create a large "adtools" directory in your Cygwin home dir)


cd ~/adtools/gild

git submodule init
git submodule update

cd ~/adtools

gild list

Should show:

binutils 2.23.2
coreutils 5.2
gcc 4.9
gcc 5
gcc 6



gild clone (takes quite a bit of time to run)

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.)

gild checkout coreutils 5.2

gild checkout gcc 5 (I wanted 5.x, not the currently-unstable 6.x branch)


For Cygwin:

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)"

Then, it's time to test the thing....

Using a text editor, ex: "nano ~/adtools/hello.c", create a simple "hello.c" source file that contains:

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

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

cd ~/adtools
ppc-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 ~/adtools
ppc-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!

This source is taken straight from http://wiki.amigaos.net/wiki/Programming_in_the_Amiga_Environment

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.
*/

#include <proto/exec.h>
#include <proto/intuition.h>

struct Library *IntuitionBase;
struct IntuitionIFace *IIntuition;

int main()
{
IntuitionBase = IExec->OpenLibrary("intuition.library", 50);

// Note it is safe to call GetInterface() with a NULL library pointer.
IIntuition = (struct IntuitionIFace *)IExec->GetInterface(IntuitionBase, "main", 1, NULL);

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.

See one of my other posts on this site on how to actually use 3rd party/new libaries/headers with this new toolchain from the Cygwin/Uwin command-line (http://www.amigans.net/modules/xforum ... m=25&topic_id=7654&order=); and yet another post on this site showing how to use Visual Studio 2017 with the Cygwin version of this toolchain for a much slicker/easier development environment outside a command-line (http://www.amigans.net/modules/xforum ... m=25&topic_id=7639&order=).

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.




Search keywords:

Search keywords:

Cross
Cross-compile
Cross-compiler
Cross-compiling
compile
compiler
compiling
adtools
Win
Windows
Bash
Ubuntu
Cygwin
Amiga Development Tools
Developer
Intel
x86
x64
PPC
PowerPC
Power PC
OS4
Ami
AmigaOS

@stonecracker

Thanks so much for this. I am starting to get some freetime and being able to cross compile would just be easier. For UWIN is that not this?

Windows Subystem for Linux

@DStastny

Happy to help, hopefully it actually _does_ help.

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.

I'm currently running Windows 10 Pro, 64-bit, Version 1607, OS Build 14393.1715. Which means I'm definitely _not_ using the latest-available UWin tools/binaries/packages.

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?

@stonecracker

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.

So looks like we need a newer version of binutils?





Doug

@stonecracker

I got it to work!

The issue I had was due to a type-o in your exports path addition.

export PATH=:$PATH:~/adtools/bin:/usr/local/amiga/adtools-ppc-uwin-20170623-404/bin

should be

export PATH=$PATH:~/adtools/bin:/usr/local/amiga/adtools-ppc-uwin-20170623-404/bin

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.

After removing colon successfully built and ran Hello World.

This was running latest Ubuntu on Windows 10 from App-store


Doug

@AmigaBlitter

Why would you copy the OS? Cross-compiler needs only the headers and libs.

@stonecracker

I get stuck at the very first git clone with the following error:
fatal: Unable to find remote helper for 'https'

So far, none of the suggestions I've found online have made any difference.

EDIT: Okay, I can work around the problem by changing https to git.

EDIT2: Okay, the same error (can't find helper for 'https') is preventing git submodule update from working...

Hans

@Capehill

Thank you, Capehill.

I edited my previous message. I mean the entire "Amiga OS4 SDK". I never had a try with cross compiling, sorry,

So only the SDK headers should be copied? As per SDL2 headers, should i copy in the same location as in the Amiga system?

Thak you

@hans

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?

@dstastny

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.

@Hans

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.

billy

@stonecracker

Quote:
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:
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.

Hans

... and just like that, it's suddenly working. I reran the Cygwin installer, and it had git plus some other items listed as "pending." Now git's handling https just fine.

Let's see how far I get this time...

Hans

FYI, all:

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.

@Hans

I didn't encounter any issues whatsoever with my Cygwin's package installer and git. Wondering if that's some odd Cygwin mirror site's glitch?

@AmigaBlitter

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.

@stonecracker

If you write up the Cygwin time permitting I will make equivalent version for UWin.

Doug

@stonecracker

Quote:
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.

Hans

@DStastny

I just posted my tome on using Visual Studio 2017 and the Cygwin-hosted adtools.

The command-line version of that same subject should be done shortly as it's a tiny subset of the Visual Studio instructions.

@Hans:

Very glad to hear! Yes, avoid spaces in directory/filenames in the entire Cygwin/adtools path.

I'll update the original post to reflect that valuable tidbit.