Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
86 user(s) are online (35 user(s) are browsing Forums)

Members: 0
Guests: 86

more...

Headlines

Forum Index


Board index » All Posts (stonecracker)




Re: Building Cross-Compiling adtools for Amiga OS4 PowerPC (ppc) with Cygwin/Bash on Ubuntu on Windows
Just popping in
Just popping in


@AmigaBlitter

Yes, you're correct, as originally written/instructed (and I'll update this guide to reflect what I'm about to say next), the adtools git repository, by default, downloads the AmigaOS4 SDK v.53.24.

Not altogether sure why it doesn't just pull down SDK v53.30 which you can get publicly from Hyperion.

Upcoming, later this week at AmiWest I hope, is the latest adtools/SDK from Hyperion.

Regardless, I'll push a simple update to the originating post of this topic showing how to download/install any OS4.x SDK from version 53.30 and up to update the SDK that gets installed into the adtools chain.

In the meantime, until I update the originating post, here's the quick lowdown:

Download the Amiga OS4.1FE v53.30 SDK lha file from Hyperion. http://hyperion-entertainment.biz/ind ... nload&layout=form&file=82

For this purpose I assume you'll be downloading the file "SDK_53.30.lha" and that it'll be downloaded to your Windows user's "Downloads" directory, aka "~/Downloads", as seen from your Cygwin or UWin bash shell. It doesn't really matter where you download that 53.30 lha file to, just note where it is, as seen by your Cygwin/UWin bash command line.

For UWin you may need to "sudo" the following commands, in Cygwin, you don't

In your Cygwin/UWin bash shell, rename the current SDK directory to reflect the version it's currently pointing to. For example:

"mv /usr/local/amiga/adtools/ppc-amigaos/SDK /usr/local/amiga/adtools/ppc-amigaos/SDK_5324"

Then, "mkdir /usr/local/amiga/adtools/ppc-amigaos/SDK_5330"

Then, pull out the following sub-archives from the v53.30 SDK archive package: base.lha, clib2-1.206.lha, and newlib-53.30.lha. Doesn't matter if you're using the Windows command-line lha command to do your .lha maniuplation, or if you're using some Windows archive software like Winzip that can extract lha's. These tips assume you're using the command-line lha utility.

For the remaining steps, I assume those 3 sub-archives are now found in the ~/Downloads directory.

Then, assuming you're using the Windows command-line version of lha, again from your UWin/Cygwin bash shell:

"cd /usr/local/amiga/adtools/ppc-amigaos/SDK_5330"

"lha -x ~/Downloads/base.lha"

"mv Include include" (changing the Uppercase Include to lowercase include).

"lha -x ~/Downloads/clib2-1.206.lha"

"lha -x ~/Downloads/newlib-53.30.lha"

"cd .."

"ln -s SDK_5330 SDK"

Repeat this every time you update your SDK, changing these instructions to reflect the version numbers of the various directories and archives as appropriate.

After doing this, anytime you want to use a particular version of the SDK to compile against, delete and then create anew your "SDK" symlink as needed.

I'm awaiting the next SDK release before I finalize these instructions and add them back to the original post.



Edited by stonecracker on 2017/10/18 5:57:29
Edited by stonecracker on 2017/10/18 5:59:45
Go to top


Re: Building Cross-Compiling adtools for Amiga OS4 PowerPC (ppc) with Cygwin/Bash on Ubuntu on Windows
Just popping in
Just popping in


@AmigaBlitter

I'm posting another of my guides shortly, hopefully in the next 2 days or so, on how to use the Cygwin or UWin adtools from the bash command line to accomplish exactly what you're asking (and more).


Go to top


Re: Building Cross-Compiling adtools for Amiga OS4 PowerPC (ppc) with Cygwin/Bash on Ubuntu on Windows
Just popping in
Just popping in


Hmmm. Did the executables get built?

If you "ls -hal /usr/local/amiga/adtools/bin"

What do you see? I'm wondering if there's any ppc-amigaos-gcc executable even there/built.


Go to top


Re: Building Cross-Compiling adtools for Amiga OS4 PowerPC (ppc) with Cygwin/Bash on Ubuntu on Windows
Just popping in
Just popping in


@AmigaBlitter

Is the /usr/local/amiga/adtools/bin directory in your PATH with the "export PATH" suggestions?

Go to top


Re: Building Cross-Compiling adtools for Amiga OS4 PowerPC (ppc) with Cygwin/Bash on Ubuntu on Windows
Just popping in
Just popping in


@AmigaBlitter

Hmmm. Not sure what's going on there.

Does the directory /usr/local/amiga/adtools-ppc-cyg64-20170623-404 actually exist?

If not, try a simple "mkdir /usr/local/amiga/adtools-ppc-cyg64-20170623-404" to create the directory first and then create the symbolic link with the "ln -s" command.

Shouldn't matter, as symlinks get created all the time while pointing to nonexistent objects. But worth trying.


Also, no, sudo isn't used for Cygwin anything. Indeed the reason I even had to fork the instructions between uwin and cygwin was solely because of the lack/missing/non-existent sudo concept in Cygwin.

Go to top


Re: Using Visual Studio 2017 to Cross-Compile PowerPC Amiga OS4 Code via Cygwin-based adtools Toolchain
Just popping in
Just popping in


FYI, anyone who's read/used this guide. I've now made a number of minor bug corrections/typo corrections. If you tried/used the original version, look at the very first editorial comment to see the summary of changes.

Go to top


Re: Cross-Compiling for Amiga OS4 PPC from Cygwin / Bash on Ubuntu on Windows 10+
Just popping in
Just popping in


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


Go to top


Using Visual Studio 2017 to Cross-Compile PowerPC Amiga OS4 Code via Cygwin-based adtools Toolchain
Just popping in
Just popping in


Using Microsoft Visual Studio (VS) Community 2017 as an IDE to Develop/Cross-Compile PowerPC (ppc) Amiga OS4.x (OS4) Binaries Using a Cygwin-GCC/G++-based Amiga Toolchain (cyg-adtools) on Windows 10

[First Published 2017-10-06. Updated to explicitly show where tab spacing should be in make files, plus a note to avoid spaces in file/directory names, and a note about the symlinks used. Updated to show use of "-gstabs" option in makefile instead of "-gdbg", and also a link to @kas1e's nice tutorial on using gdb on OS4. Updated to describe adding other Include and Library search paths in makefile for 3rd party or other headers/libs.]


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

1) A post 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 the first post, from a Windows / cygwin command line (http://www.amigans.net/modules/xforum ... m=25&topic_id=7654&order=)

3) The post you're reading now, on how to use the toolchain built in the first post from inside Visual Studio for Windows (http://www.amigans.net/modules/xforum ... 9&forum=25&post_id=108233) ]



Prelude:

This guide is long. Very long. It's not long because it's difficult or even time consuming to accomplish its goal, which is to get Visual Studio to use your nice new Cygwin-hosted adtools. It isn't. It's actually really fast/easy -- once you know what you're doing. I actually can get a new cross-compiling Amiga OS4 source project set-up/going in Visual Studio inside of 30 seconds.

The "know what you're doing" is the lengthy part, and that's what I'm hoping to impart onto you, to help save you the insane time it took me to catch every tiny little nuance of making this work, because some of it was absolutely counter-intuitive and unexpected.

To accomplish this setup for all your future projects, you need to gain some knowledge on the workings of VS and how it interacts with Cygwin and the Cygwin-hosted adtools toolchain.

So, I've attempted to craft a truly complete and entirely self-contained guide. That means it's rather verbose. But hopefully you only need this guide (plus the pre-requisite one) to get everything going. Hopefully, you won't need to read 100's of posts and chains of conflicting/out-of-date information.

Why bother?

Because VS is slick, and makes AmigaOS/OS4 coding (any coding, really) that much more enjoyable and easy. Unless/until a great native/Amiga IDE is released, cross-compiling is not only a good idea -- it's mission critical. I say this because creating a great/comfortable cross-compiling toolset a pre-requisite in my mind to keeping/attracting developers for OS4 because the more barriers we have (i.e., forcing the legions of Windows/Mac/Linux-based developers to abandon their favourite non-Amiga dev environments, just to develop for the beloved AmigaOS), the less developers we have.

I, myself, was very much in the same boat -- just trying to get either a native or cross-compiling toolchain going was a painful ordeal. I (like all other devs who've stuck around or are just now coming back to the OS) had to make a choice -- burn a bunch of hours to get this going smoothly, or stop trying and abandon a 25-year reunion with my all-time-favourite OS, or ... burn an _insane_ amount of time just getting cross-compiling toolchains and IDE's to work and write about it so others wouldn't have to.

VS and the cyg-adtools package can offer an Amiga OS4 C/C++ developer a really powerful, modern, robust, heavily developed, and as-up-to-date-as-you'd like, cross-compiling Integrated Development Environment on Windows 10. There are countless plugins constantly being developed for VS, and since VS Community 2017 (and probably beyond) are now given away by Microsoft at zero cost, VS has been exploding in popularity. A wise move, in my opinion, to help Microsoft stem their losses in the massive global development community who may otherwise have little (or zero) need to develop on, or for, Windows.

VS definitely is _not_ the lightest-weight / smallest-footprint / fastest-running / easy-to-use IDE in the world. It _is_ one of the most powerful and popular ones -- and not just for C/C++ developers anymore, and also not just for Windows developers anymore.

Really the only thing that modern developers would like that is missing from this guide is the ability to have VS and its tools act as a tightly-integrated front-end for remote debugging (ex: VS running VisualGDB or WinGDB or remote gdb on Windows, with a remotely-connected instance of gdb running in your Amiga environment). The missing piece to get remote debugging working is how to make a virtual serial or SSH connection from the Amiga environment to a Windows one. I think it's possible. I just haven't worked on the issue. If I do figure it out, I'll post another guide on that subject as well.

This guide was developed using VS Community Edition 2017. I assume that all commercial/paid-for editions of VS would work as well. Additionally, this entire setup will also probably work just fine on Visual Studio Code 2017, maybe verbatim, if using Visual Studio Code on Windows.

But, that aside, I think it's really interesting that this entire setup (or at least the concepts) could work on Visual Studio for Mac and Linux. If so, then a new guide is very much warranted as the instructions would definitely have to change given that Mac and Linux don't use Cygwin at all (they don't need to ...the gcc tools would be native), so the set-up would be somewhat different. That is, you _wouldn't_ be using VS Code 2017 on Mac/Linux with the cyg-adtools package, you'd instead be generating and using an entirely different adtools package for Mac or Linux gcc/g++, and using makefiles from Visual Studio Code to access those cross-compiler binaries. At any rate, hopefully this guide can help with that if anyone tackles that effort.

Lastly, these instructions were supposed to be part two of two: part one being how to integrate the cyg-adtools package with the Eclipse IDE on Windows. However, my attempts to make that work were so awkward and difficult that I realized it would just be faster/easier to use a good developer's text editor and a Cygwin command shell. In other words, because of my horribly bad run-ins with Eclipse's setup environment refusing to use the adtools cross toolchain in Cygwin, and being really finicky with makefiles, I found that having no IDE whatsoever was far superior to trying to get Eclipse and cyg-adtools to work. It's almost certainly _not_ Eclipse's fault per se, I actually think it's a good IDE, I just couldn't figure it out.

The setup described here, by contrast, works really well, and borrows heavily from an older article on this subject, found at:

http://www.amigacoding.de/index.php?topic=18.0


If you _don't_ want to use an IDE at all, and instead just your favourite Windows editor, your Cygwin/UWin bash shell, and the cyg/uwin-adtools, then ignore this guide entirely and instead check-out:

http://www.amigans.net/modules/xforum ... m=25&topic_id=7654&order=



Pre-Requisites:



Before using _this_ guide, you should first read/complete the _other_ guide I wrote on building the Cygwin-based "adtools" package directly from the adtools source repository on github.

All of these instructions here fundamentally assume you've followed my other guide. Check out:

http://www.amigans.net/modules/xforum ... hp?topic_id=7623&forum=25

The impetus for this guide is that I discovered the exact same problem with this subject matter as in my prior one, namely there is nothing but outdated information about using Windows Integrated Development Environments (IDE)'s with any Cygwin-based AmigaOS/OS4 adtools cross compiler toolchains.

In this guide, I instruct on how to pick up where my other guide left off ... that is, I discuss how to bring my other guide's resulting Cygwin-hosted adtools cross-compiling chain into VS in an almost-seamless/almost-complete manner. Literally the only thing missing that I could see with this set-up is a functioning remote debugger to remotely run gdb on your Amiga OS4 test environment from your VS workstation.

I cover only the Cygwin toolchain here. Although my prior guide showed how to build the adtools toolchain on UWin (Bash on Ubuntu on Windows/Linux Subsystem (LXSS)/Windows Subsystem for Linux (WSL)), this guide doesn't show how to actually use that particular toolchain from inside Visual Studio. That's the subject of another guide I may yet produce (or not -- folks, feel free to take up that task).

Knowledge about GNU make/gmake/make files is helpful. This guide does, afterall, try to continue the paradigm of porting as much of the standard GCC/G++/gmake/make-based Linux C/C++ development methods/processes into the Windows environment as we can. Central to that is the ability to create some simple "make" files.

If you choose to use Visual Studio to create/edit Amiga source packages, then it's important to realize that your source package might be used by other developers (or yourself) in some development environment that is _not_ VS. So, to avoid the _guaranteed_ collisions/problems that would otherwise happen if we were not careful, these instructions specifically do NOT use the standard "makefile" naming conventions. Instead, we use the filenames "makefile.vs" and "makefile-dbg.vs" so that any developer who's expecting their standard command-line toolchain calls to work with non-VS/standard makefiles named "makefile" _won't_ get tripped up by you using VS in your development efforts.

By extension, this means if you intend to distribute your Visual Studio-developed source package to anyone, because other developers may not be using VS, you'll probably need to create both a standard make file named "makefile" AND your VS-specific "makefile.vs" and "makefile-dbg.vs" make files described herein.

Indeed, this is THE central idea of this guide: it's the VS-specific makefiles, (and some VS settings) that do the heavy lifting to force VS to actually use your cyg-adtools toolchain to create AmigaOS binaries.

And remember, the price to pay for using Visual Studio is that these makefiles and settings _must_ be created and configured for _every_ Amiga OS4.x cross-compiled project that you want to manipulate inside VS. It's a small price to pay, in my mind.

VS + cyg-adtools is, truly, slick and powerful. I don't give Microsoft much credit very often. They deserve kudos for making Visual Studio Community 2017 both excellent and free.



How-To:


Phew. Enough intro. Let's get to it.

TIP: In everything below, avoid using spaces in any directory name or file name. Save yourself some sanity because the resulting errors can be infuriating.


1) If you've not already done so, follow all the steps needed to create your Cygwin gcc/g++ setup and the Cygwin-hosted adtools toolchain from source. Go to the top of this guide and follow the link there if needed.

2) Install VS Community 2017. Once installed, run it, and add the VS "Linux Development with C++" Toolset using the Tools->Get Tools and Extensions menu option. Close VS.

3) Add the Cygwin "bin" directory to the Windows path. To do this, access the Windows 10 path settings by clicking on:

Windows Start Menu Button->Settings (the cog/wheel icon).

In the "Find a Setting" search box, type "view advanced" and the "View Advanced System Settings" auto-complete option should show. Click on it.

Then, the System Properties dialog box will display.

Click the "Environment Variables..." button.

In the System Variables sub dialog area, you should be able to scroll in that box and find the environment variable named "Path". Click on "Path" to highlight it, then click on the Edit button.

Add the "C:\cygwin64\bin" directory to the bottom of that pop-up Path Edit dialog box.

Click OK on all the dialog boxes you just launched.

You definitely want to reboot your machine to ensure this system path is now being used.



4) After reboot and login, start Visual Studio again.

5) Create a new project (File->New Project).

In the New Project dialog box, in the left-hand side Project Type selection tree (not labeled as such) select:

Installed -> Visual C++ -> General

In the middle pane, select Makefile Project.

Enter a name/directory of your project. For this guide, create a Project named "CygVsMakeProject1", and save it to VS's default $HOME\source\repos directory.

Note that VS 2017 contains "Projects" inside collections called "Solutions". A Solution can have many Projects. By default VS will create a Solution named the same as the first Project you create. That is, in VS's Solution Explorer window, you'll have a "CygVsMakeProject1" Solution that contains a single project also named "CygVsMakeProject1". Don't confuse the two in the following instructions.


6) You'll next be presented a large dialog box asking about your Debug Configuration Settings and about your Release Settings. These are 2 profiles you can use to effect 2 different types of builds, one with debug symbols inserted into the binaries and one without.

We'll definitely want to take advantage of VS's nice ability to do that, which means we'll use 2 different, but very similar, makefiles (see below) for this purpose.


In the Debug Settings dialog box:

The makefile referenced in these settings ("makefile-dbg.vs") _includes_ the compiler options for adding debug symbols to the object files/executables.

For both the "Build command line" and "Rebuild command line" fields:

make -f makefile-dbg.vs 2>&1 | sed -e 's/\(\w\+\):\([0-9]\+\):/\1(\2):/'


For the "Clean command Line" field:

make -f makefile-dbg.vs clean


For the "Output (for debugging) field:"

$(ProjectName)-dbg


Leave the other fields blank for now. Click Next.


Release Settings dialog box:

This is essentially the same settings as the Debug settings, but we need to reference a make file that _excludes_ any debug symbols from being inserted into binaries. This makefile is called "makefile.vs"

Uncheck the "Same as debug configuration" selection box.

For both the "Build command line" and "Rebuild command line" fields:

make -f makefile.vs 2>&1 | sed -e 's/\(\w\+\):\([0-9]\+\):/\1(\2):/'


For the "Clean command Line" field:

make -f makefile.vs clean


For the "Output (for debugging) field:"

$(ProjectName)

Leave the other fields blank for now. Click Finish.


7) Time to create the 2 makefiles referenced above. To understand the files you're about to create, know that in this guide, we'll be creating a small program called "easy" whose source filename is "easy.cpp". "easy" is a trivial, but really good, Amiga-specific example to prove that we have everything needed to create a true Amiga program, not just some standard portable C/C++ binary that doesn't use any AmigaOS-specific functions. The program itself is super-simple, when run, it just flashes the Workbench screen.

And now the interesting knowledge bits....

Very interestingly, our Cygwin-based makefile/make environment is a mix of both Windows/Cygwin execution spaces and command formatting. For example, the makefiles are written in pure POSIX style, complete with forward slashes for directory names, and respecting such things as Cygwin symbolic links/etc (but _not_ Windows backslashes and _not_ Windows junctions/symlinks).

Yet we still have Visual Studio running in a standard Windows execution space and it either directly or indirectly via the makefiles, calls such things as "make" and "ppc-amigaos-g++" and "rm" commands from the Windows environment -- not a Cygwin bash shell. "make" and "rm" aren't at all Windows commands, yet this works. It's why we needed to place the C:\cygwin64\bin directory into the Windows System Path variable so Cygwin could do its magic. And, despite all this mix of Windows/POSIX commands/filesystem namespaces, Windows execution spaces, etc. it all flows effortlessly. Cygwin makes all that possible/nearly automatic.

But you, good Amigan, need to keep some things straight in your head.

For Visual Studio anything -- in all VS dialog boxes, settings fields, non-makefile scripts, plugins, configuration settings, etc., use only standard Windows conventions/naming/filenaming/backslashes/"C:"/etc. (but never forward slashes or Cygwin-created symlinks)

Inside makefiles -- use only POSIX standard conventions as understood by Cygwin, like forward-slashes in directory names, and use of Cygwin/bash-created symbolic links, but never back slashes or "C:"

This is important and is easy to confuse.

This means that although in VS, you'll reference a given source tree or file or directory using standard Windows syntax, those very same files and directories that you'll be hammering away at with your cross compiler toolchain inside the makefiles must be referenced differently.

Now, back to the instructions...

In VS, with the newly-created project open and selected (remember, you must have the Project selected, not the Solution, when doing this), do the following:

Project -> Add New item -> Utility -> Text File

In the resulting Text File dialog box:

Change the default filename shown from "Text.txt" to "makefile.vs". Make sure you _don't_ have "makefile.vs.txt" as the filename. You can save that file to its default location.

Repeat these steps immediately above to add another text file, and call it "makefile-dbg.vs". You can save that file to its default location.

In the left-most pane (VS's Solution Explorer window) you should now see 2 child objects of the CygVsMakeProject1 project you just created. Those 2 child objects should be the 2 makefile text files. They should be in the Project directory, not some subdirectory like the "source" directory. If they are in a subdirectory, move them back up to the Project directory.


8) Let's edit each of the makefiles now.

Note, I'm assuming you've followed my prior post on creating the adtools chain from source, which put the binaries in the location referenced below, and have also created symlinks that are relied-upon below.

Please note!!!! Those are TABS in the second/indented line beneath each of "all" and "clean". They're not spaces, you must use a tab indent. Don't forget those!

In the VS editor pane, you should have "makefile.vs" already open, copy/paste the following into that file (remembering that you should check for, or just manually put in, a tab in those indented lines):

all:
<put a tab here> /usr/local/amiga/adtools/bin/ppc-amigaos-g++ -o easy easy.cpp -Wall -I/usr/local/amiga/adtools/ppc-amigaos/SDK/include

clean:
<put a tab here> rm easy


Similarly, in the "makefile-dbg.vs" editor window, copy/paste the following into that file (remembering that you should check for, or just manually put in, a tab in those indented lines):

all:
<put a tab here> /usr/local/amiga/adtools/bin/ppc-amigaos-g++ -gstabs -o easy-dbg easy.cpp -Wall -I/usr/local/amiga/adtools/ppc-amigaos/SDK/include

clean:
<put a tab here> rm easy-dbg


Save both the "makefile.vs" and "makefile-dbg.vs" files.

Some words about both makefiles for your own knowledge/future use.


1st, note the use of POSIX syntax throughout. This includes forward slashes and a reliance on a symlink created earlier if you followed my pre-requisite guide.

2nd, note the absolute Cygwin-based path/filename to reference the specific Amiga g++ cross compiler executable.

3rd, note the -I option, which is how I can specify the includes search path so that the amigaos-g++ compiler knows where to find the Amiga and other headers I'd like to use. The way I've set this up, Visual Studio doesn't actually communicate much with the makefiles except to invoke them; that's why they have to be so involved/detailed in things that might otherwise be passed-in as parameters in any other IDE/makefile environment. IN ORDER FOR YOU CODE TO COMPILE/LINK, YOU ABSOLUTELY MUST ENSURE THIS MAKEFILE INFORMS THE COMPILER OF YOUR INCLUDES SEARCH PATH! Use a '-I' for every directory needed. That might mean realllllly long commands with lots of long '-I' statements but that's fine.

Similarly, though not shown in this example, just like the '-I' option, you need to add '-L' options to tell the linker what directories to search for libraries to link against. Has the same syntax as the '-I' option, and use another '-L' for every directory that needs to be searched.

4th, these are stupid-simple makefiles. You can make much, much, smarter ones than this. There are lots of ways to avoid lots of long '-I' and '-L' entries for example.

But I've shown this as-is because the information here is the _minimum_ you need to have these makefiles work with VS and your Cyg-adtools. You might be able to use passed-in parameters from Visual Studio instead of stupid hard-coding of things like the include path or even filenames of anything. You might also be able to use environment variables to avoid any hard-coding of filenames/paths in a makefile. You probably can use parameterized substitutions to allow for a super-smart 100% generally re-usable makefile that you just copy/paste into 100% of your Visual Studio Amiga projects without a moment's thought. Please feel free to do so and post your improvements in comments to this guide.



9) Now, let's to the simple thing, copy/paste-in some code into a file named easy.cpp.

Create easy.cpp by again selecting the Project named CygVsMakeProject1 in the Solution Exploerer window.

Then, choose Project -> Add New Item -> Visual C++ -> C++ File (cpp)

In the filename dialog, keeping the same default directory supplied by Visual Studio, change the file name to "easy.cpp" and click "Add"

In the Solution Explorer, you should then see a single node in the "Source Files" tree, which is the one file you just added called "easy.cpp"


10) Copy/paste the following into the "easy.cpp" file's edit window.


/* easy.cpp: a complete example of how to open an Amiga function library in C/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);
}


11) Save the easy.cpp file. Use the "Save all" button in the VS toolbar, just in case you missed saving a bunch of your work to this point.

You're (finally) ready to build/compile/test.

12) Let's test this set-up!

In the profile dropdown (in the toolbar, just underneath the "Debug" and "Team" menu items), you should see the options "Release" and "Debug".

Beside that drop-down is a platform selection dropdown. Ignore that one.

Now, choose "Debug" from the profile dropdown.

Then choose Build -> Build CygVsMakeProject1

Check out the Output window at the bottom right of the VS screen.

If all is good, in a second or two, you should see...

1>/usr/local/amiga/adtools/bin/ppc-amigaos-g++ -ggdb -o easy-dbg easy.cpp -I/usr/local/amiga/adtools/ppc-amigaos/SDK/include
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========



Then, from the profile drop-down, choose "Release".

And again, choose Build -> Build CygVsMakeProject1

Which should show in the Output window...

"1>/usr/local/amiga/adtools/bin/ppc-amigaos-g++ -o easy easy.cpp -I/usr/local/amiga/adtools/ppc-amigaos/SDK/include
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped =========="

Which means you now have 2 AmigaOS OS4 PowerPC executables, one named "easy" and another named "easy-dbg" in the Project's directory (ex: C:\<path to user's Windows home dir>\repos\<SolutionName>\<ProjectName>)



13) Go test "easy" and "easy-dbg" by running those executable files in your AmigaOS environment from a command shell. If the Workbench screen flashes once each time you run those programs, you're good to go!

You now have a slick cross-compiling Visual Studio 2017 environment for you to develop away.

You can update the adtools compiler chain at any time, just by following the instructions in my prior post, and if you follow those directions closely (especially the symbolic linking I mention throughout), then the only changes you'll to make to keep Visual Studio "in the loop" is to update your Windows-side symlink (the "adtoolsln" link) described below to allow VS's IntelliSense to keep using the latest header files for its syntax/content lint'ing. More on this below.



What About Existing Code?

All these examples above have created new files from scratch. But what about all those Amiga OS4 programs and existing code trees? With resources/libraries/etc?

This is rather beyond the scope of this guide. But as a pointer, you can't just copy source packages into some VS project directory and assume Visual Studio knows about the files. Look into Visual Studio's "Project -> Add Existing Item" option or "File -> Open Folder..." functionality.


What About Debugging?

As noted above, the only thing missing from this guide is a nicely-integrated, single-step, source-level, remote debugging interface.

While that's certainly true unless/until I (or someone reading this) solves the remote gdb connectivity issue between your OS4 test environment and your Visual Studio development PC, manual debugging using gdb on the OS4 environment works like a charm.

If you'd like to know how to do this, a nice shout out goes to @kas1e for his tutorial on using gdb in an Amiga environment, which you can find at:

http://www.os4coding.net/blog/kas1e/gdb-beginners

If you follow his tutorial, you'll find that the debug versions of the binaries built from this setup here will work beautifully. Suggest that if you do use gdb, that you also copy to your Amiga OS4 test environment, all the source files used to build your OS4 binaries, into the same directory where your binaries are copied -- that way gdb can easily reference your source as needed.



And, Finally, Getting IntelliSense to Work

One of the most valuable features of Visual Studio is its IntelliSense code completion/monitoring/profiling abilities....But it's useless if it doesn't know the code/headers it's supposed to be using.

If you look at the "easy.cpp" code file in its editor in Visual Studio, you'll see lots of red underlines and warning symbols and errors. That's because we don't currently have the CygVsMakeProject1 project set-up correctly to tell IntelliSense where to find all the AmigaOS headers (well, actually, any headers used by the .cpp file in question, not just AmigaOS SDK ones).

Let's fix that.

For your sanity, in anticipation of future updates to your adtools chain, create directory symlink in Windows by launching an Administrator Command Prompt. (Find your Command Prompt item in your Windows start menu, right-click on it, then right-click again on the "Command Prompt" sub menu item, and choose "Run as Administrator").

Then:

cd c:\cygwin64\usr\local\amiga

And create a Windows/NTFS synbolic link (which you'll definitely need to redo every time you build a new version of the adtools chain so you're always pointing to the latest version of the headers).

mklink /D adtoolsln adtools-ppc-cyg64-20170623-404

[Note, use "adtoolsln" and _not_ "adtools" as your link name, because if you've followed all my instructions to this point, you already have an "adtools" symlink/junction file -- one that was created and used in the Cygwin setup to begin with].

Close that Command Prompt window.

Return to Visual Studio

Then with the CygVsMakeProject1 Project selected in the Solution Explorer:

Select Project -> Properties -> NMake

In the resulting dialog box, in the "Configuration" drop-down chooser, select "All Configurations"

Then, still in that dialog select NMake -> IntelliSense -> Include Search Path

And enter the following into the IntelliSense's Include Search Path value field:

C:\cygwin64\usr\local\amiga\adtoolsln\ppc-amigaos\SDK\include\include_h;C:\cygwin64\usr\local\amiga\adtoolsln\ppc-amigaos\SDK\clib2\include;C:\cygwin64\usr\local\amiga\adtoolsln\ppc-amigaos\SDK\newlib\include

And you'll definitely want to add any other include directories you'd like to have IntelliSense know about. Basically, whatever include directories you want in your make files for a given project, you'll probably want to have here, using Windows path/filename syntax.

But remember, all of this is just for the editor's error/warning highlights. None of these settings affect the Include search path of the actual gcc/g++ compilers. Again, the makefile include search paths probably will mirror the IntelliSense Include search paths -- albeit with different POSIX syntax.


*** That's all folks ***

In the end, it's actually quite fast/easy to do everything here. You'll probably repeat all these steps like I do inside of 30 seconds when you need them.

I just figured you'd want all the backgrounder/underlying knowledge needed so you can adjust to suit your needs in the future.



Some credits:

In the original posting which I drew a bunch of this information from (see above for full link URL), the author EDanaII, when they posted their message back in 2012, which itself was a repost, had a note of thanks at the end of the message. I'm copying that verbatim here: "I'd like to thank SG2 for his initial help in getting this working, and Hans for helping me publish the article!"

And now, my turn. I very heavily edited and of course heavily added-to the original post from EDanaII. I don't know EDanaII, but thanks go out to him/her for their work -- and additional big thanks to the original poster which EDanaII reposted from. Let's hope this helps to keep the effort going.



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


Edited by stonecracker on 2017/10/6 13:39:00
Edited by stonecracker on 2017/10/6 15:15:22
Edited by stonecracker on 2017/10/7 0:15:17
Edited by stonecracker on 2017/10/7 1:09:01
Edited by stonecracker on 2017/10/7 20:34:09
Edited by stonecracker on 2017/10/8 9:19:26
Edited by stonecracker on 2017/10/21 10:59:47
Edited by stonecracker on 2017/10/21 11:05:23
Edited by stonecracker on 2017/10/21 23:11:13
Edited by stonecracker on 2018/10/25 15:37:47
Edited by stonecracker on 2019/10/26 22:16:27
Go to top


Re: Cross-Compiling for Amiga OS4 PPC from Cygwin / Bash on Ubuntu on Windows 10+
Just popping in
Just popping in


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


Edited by stonecracker on 2017/10/5 13:22:35
Go to top


Re: Cross-Compiling for Amiga OS4 PPC from Cygwin / Bash on Ubuntu on Windows 10+
Just popping in
Just popping in


@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?

Go to top


Re: Cross-Compiling for Amiga OS4 PPC from Cygwin / Bash on Ubuntu on Windows 10+
Just popping in
Just popping in


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.

Go to top


Re: Cross-Compiling for Amiga OS4 PPC from Cygwin / Bash on Ubuntu on Windows 10+
Just popping in
Just popping in


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

Go to top


Re: Cross-Compiling for Amiga OS4 PPC from Cygwin / Bash on Ubuntu on Windows 10+
Just popping in
Just popping in


@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?

Go to top


Re: Cross-Compiling for Amiga OS4 PPC from Cygwin / Bash on Ubuntu on Windows 10+
Just popping in
Just popping in


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


Go to top


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


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


Edited by stonecracker on 2017/10/5 12:34:56
Edited by stonecracker on 2017/10/5 12:39:25
Edited by stonecracker on 2017/10/5 12:41:10
Edited by stonecracker on 2017/10/5 12:45:51
Edited by stonecracker on 2017/10/6 13:35:06
Edited by stonecracker on 2017/10/6 23:06:24
Edited by stonecracker on 2017/10/7 21:24:15
Edited by stonecracker on 2017/10/8 9:11:07
Edited by stonecracker on 2017/10/18 6:12:47
Edited by stonecracker on 2017/10/18 6:21:36
Edited by stonecracker on 2017/10/18 6:25:37
Edited by stonecracker on 2017/10/18 6:28:36
Edited by stonecracker on 2017/10/19 15:18:35
Edited by stonecracker on 2017/10/21 23:14:37
Edited by stonecracker on 2018/2/27 20:52:14
Edited by stonecracker on 2018/10/25 15:38:18
Edited by stonecracker on 2019/10/26 22:08:00
Go to top


Re: We so need an updated browser!
Just popping in
Just popping in


@ChrisH


I like AmiDevCPP, but wanted a much more supportable/plug-in/build-from-source alternative that didn't bundle in any IDE.

Less of a code maintenance problem when we can always pull from a central adtools Git repo and go from there with anyone's favourite IDE.

The natural choice for AmiDevCPP was Cygwin, of course, as was mine.

I figured putting the instructions on the Cross-Compiling thread would be a natural fit. But perhaps a new thread entitled Cross-Compiling for Amiga OS4 PPC from Cygwin / Bash on Ubuntu on Windows 10+?

Might help with general Google searching with such a title. Make it easier for other Amiga developers/potential devs to find.


Go to top


Re: We so need an updated browser!
Just popping in
Just popping in


I note that some months ago, some posters/readers here noted the issues around the OS4 developer toolchain, native vs. cross-compiler, etc. being a barrier to development of a new browser/updated browser.

I couldn't agree more. I indeed just experienced a day and a half of irritation with the same thing.

But I got a perfectly functioning cross-compiling toolchain working on Cygwin64 for Windows 10 x64. Same machine I'm running an AmigaForever7 + OS4 for Classics + AmiKitX + FlowerPot-installed OS4 emulator on.

That's using a gcc 6 compiler on Cygwin to generate a gcc 5.4 toolchain for OS4.

I almost got the exact same toolchain working for bash-on-ubuntu-on-Windows (uwin) setup.

I simply couldn't find good/complete/updated instructions on how to do this -- anywhere. So I set out to fix that myself.

I've set out the very detailed/step-by-step instructions on the cross-compiler thread on this site for posterity and to save someone else a day (or week!) just trying to get going. Bottom line, most developers simply will throw up their hands long before that time. Can't blame them.

My instructions, while focused on Cygwin and uwin should be helpful to any *BSD/Linux/Mac developer too.

Meaning, one more barrier to entry is hopefully removed, either completely, at least mostly, for someone else.


Go to top


Re: Cross compiling
Just popping in
Just popping in


HOW TO build an Amiga / OS4 32-bit gcc 5.x cross-compiler/cross-compiling tool chain running in Windows with Cygwin/Cygwin64, or ALMOST WORKING -- bash-on-Ubuntu-on-Windows (UWin) 10 Pro 64-bit -- ALMOST WORKING.

Following a good suggestion on this, I've moved this post to a new topic thread...


Edited by stonecracker on 2017/9/26 22:22:58
Edited by stonecracker on 2017/9/26 22:28:01
Edited by stonecracker on 2017/9/26 22:57:41
Go to top


Re: Cross compiling
Just popping in
Just popping in


FYI:

I have just finished a complete, functioning, repeatable, detailed, up-to-date-as-of-yesterday set of instructions to create a Windows/Cygwin-hosted (gcc 5.4 / gcc 6 Cygwin side) cross-compilation toolchain setup that uses the adtools source to build, from scratch, the OS4-targeted gcc 5.4 cross-compiler/toolchain.

I also have 99% bash-on-ubuntu-on-windows (uwin) build-adtools-from-source equivalent as well. It just has some error in what I think is the very last step in the toolchain make process.

Happy to post the Cygwin/uwin instructions here. Indeed, was about to.

I imagine the uwin instructions would be very helpful to any Linux / Mac user. I've not tried them out on Linux.


Go to top


Re: thread support compiled in the C++ runtime
Just popping in
Just popping in


Hi all.

I've made a few inquiries and posts on this topic in the "We so need an updated browser" thread.

Looking at github repo, it looks like someone last commented there back in July.

Does anyone know where the bouncing boing ball landed on this?

Pardon the potential cross-post. In this thread, I'm inquiring specifically about the adtools/git repo posts on C++11 threading support in the GNU C++ Standard Library for adtools in GCC 5.3.0 -- irrespective of its use (i.e. supporting a browser port, the topic which led me this problem).

It's clear to me that a full C++11 Std Lib is a foundational problem/solution, and that threads/pthreads is the sub-issue (or more specifically the lack thereof).

If I can find a way to throw in some hours/people at the issue, I'm absolutely going to coordinate with the adtools maintainers before/during/after doing anything.

At this point, I'm wondering about people's thoughts/up-to-date awareness on these 2 issues...

thread support compiled in the C++ runtime #12

and

Issue with std::mutex (c++11) #34

Go to top



TopTop
« 1 (2) 3 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project