At AmiWest 2019 (can't believe it's my 3rd!!! time here now, 1st time I was editing my Cross-Compiling OS4 tomes), have heard-tell that there may be something broken with these instructions.

Can anyone inform me of any breakage? I'll see if I can make updates/corrections and update my original post if needed.

At AmiWest 2019 (can't believe it's my 3rd!!! time here now, 1st time I was editing my Cross-Compiling OS4 tomes), have heard-tell that there may be something broken with these instructions.

Can anyone inform me of any breakage? I'll see if I can make updates/corrections and update my original post if needed.

At AmiWest 2019 (can't believe it's my 3rd!!! time here now, 1st time I was editing my Cross-Compiling OS4 tomes), have heard-tell that there may be something broken with these instructions.

Can anyone inform me of any breakage? I'll see if I can make updates/corrections and update my original post if needed.

Great question.

TL;DR: If Mono framework gets ported to OS4 on PPC, then, yes, the stack of methods/techniques/approaches/software that I show in this and my related posts would almost certainly work -- verbatim -- to target/cross-compiled/ported .Net/C# code to OS4 -- with or without Visual Studio.

Long-ish answer:

Visual Studio isn't the issue. .Net/C# support is.

Visual Studio is just a (very good) IDE with built-in .Net/C# support because MS decided they wanted to support C# out-of-the-box. VS itself, though, can support almost any language, native compiler, cross-compiler, remote-cross-compiler-on-Linux, and/or framework imaginable.

Now, .Net/C# support for OS4 is non-existent at the moment, and probably won't ever come directly via MS as they will almost certainly never support OS4.

However, the amazingly feature-rich/complete/open source .Net clone aka Mono Framework (heavily supported by MS) with its fantastic .Net JIT engine, and C# compiler, is definitely a strong possiblity.

I say this because Mono/C# has already been ported to OSX/x86, Linux/x86, Linux/ARM64, plus a number of little-endian PPC POSIX environments, see https://www.mono-project.com/docs/abou ... ported-platforms/powerpc/

Given the strong support for Mono on both big- and little-endian PPC OS's (including Linux), it's probably quite doable as a port to OS4.

If that happens, then, yes, we can not only have C# code just cross-compile to OS4 but we can have an ocean of .Net code run on OS4. We would even be able to natively compile C#/.Net code on OS4.

All of which would be independent of the IDE involved.

But, lastly, the question of Visual Studio support of .Net/C# on OS4 would be, yes, it would work as just another Mono target like Linux or OSX on PPC or x86.

The catch: all the things needed (C11/C++14/full POSIX multi-threading/etc) to get all modern software (browsers/office suites/etc.) ported to OS4 are also needed to get Mono/.Net/C# working on OS4.

Of course, if we had the entire oceans of GNU C11/C++14-reliant software, and .Net/Mono software, available for OS4, all easily cross-compiled via the latest Visual Studio or other Windows IDE .... just, wow.

Another of my lengthy, sporadic posts...

@Hans

That's fantastic news. As we've noted on this site (many other threads), and on countless other posts on the Internet, the single biggest technical hurdle, by far, to getting fantastic/modern/everyday-useful software ported to OS4 is the lack of a complete C++ 11 Standard Library.

In all my discussions with the Amigan-powers-that-be, the biggest hurdle to that, in turn, is some easy, rote, but somewhat time consuming, pthread wrapper calls being hammered in to the OS4 port of GNU c++stdlib.

When I see him next, I'll ask Solie if he's had anything to do with actually implementing the threading he/I have been talking about at the OS layer -- his work at the OS level, plus C++stdlib work at the GCC level, should massively assist in unlocking an incredible amount of porting options for all the software any modern Amigan needs/wants.

If you add a complete OS4-port of c++stdlib to a complete/usable OS4 SDK that can, in turn, be used natively or (especially) from a cross-compiling dev setup on a Windows machine.....well, the options keep opening up waaaaay further.

I'm glad _someone_ took some of the charge and started some work on the C++ Std. Lib. stuff. A little disappointed in myself that it wasn't me... But alas, such is my insane schedule.

This summer, I can hopefully tackle updating this thread's particular instructions for cross-compiling (from Cygwin with GCC8); and also hopefully confirm / help shore-up the C++ Standard Library stuff, whether for native-OS4 developers or for cross-compiler/Cygwin OS4 devs.

Before Christmas, I'm also hoping to free-up enough time to help with the _much_ bigger effort in rounding-out a bunch of really important/really big, but absent/incomplete OS4 SDK work that's sorely needed, again, whether for native- or cross-compiling OS4 developers.

What do I mean by "absent/incomplete SDK" work? Well, not saying I can actually achieve this by Xmas -- and it's amazing to me that _any_ OS4 software has been successfully built without this -- but _one_ example of what's missing from the SDK is a native, or UAE-emulated, or QEMU-emulated, OS4 system that can actually run GDB Server ... so that OS4 developers can _finally_ do what almost every O/S offers: a simple remote debugging session, to make single-step source-level debugging not only possible, but in fact, easy.

If the people tackling the C++ 11 Std. Lib. work can finish that work, and I can free enough time to help with the SDK / Windows cross-compiling SDK, we have a real shot at getting some serious software ported.

Think, TenFourFox for MacOSX PPC being ported to OS4 (TenFourFox is a continuously-maintained Firefox port to PPC complete with full HTML5 support and JIT'd JavaScript interpreter and Firefox extensions).

Why do I mention all of this here?

Think about having all of this porting infrastructure available, for free, to port the hundreds of code bases out there in the world that are otherwise inaccessible to OS4; all running on some Windows-based developer's machine with that developer getting up/running from scratch inside of an hour or so.

THAT, is a game changer.

THAT (I believe) means 2 massive barriers can be eliminated to help get monster volumes of code ported to OS4: 1) the underlying code infrastructure (GCC8 with c++stdlib) and 2) the developers (usually, running Windows dev tools and _not_ wanting to spend a month getting going).


Only 3 road blocks, in turn, that I can see to getting to _that_ state...

1) C++11 Standard Library,

2) a Windows-hosted OS4 emulator capable of supporting remote debugging inside it (plus some other SDK stuff), and

3) an OS4 SDK that can used inside a Windows/Cygwin cross-compiling environment.

Someone else looks to be tackling #1; hopefully, they'll need only a small amount of help and Solie's work at the OS level (which I think he's able/willing to do -- but don't quote me on that). Anyone who can help, I'm sure, will have a welcome reception to do so. I just haven't freed the time.


I've already finished #3; with only minor updates needed to accommodate GCC8.


That leaves #2. Big task, but I think doable. Interestingly, this one isn't the exclusive realm of software developers -- Windows / OS4 power users can help a bunch.

I've discussed much of this with one of the adtools/SDK maintainers (Krystian) and I'm happy to direct folks on the missing chunks that they might be able help with (ex: getting OS4 to run in QEMU or getting some low-level serial GDB traffic working in UAE).

Well, Amigans, my apologies for not logging in for several months. As predicted, I've been stupid-swamped since November 2017.

Where'd the bouncing boing-ball land on this for the new GCC 8 build?

I'll happily update my original post, again, to avoid people having to read all the comments/chain.

Glad to hear. I _think_ all is working fine with my instructions, as seen in the originating/but heavily edited, original post. UWin, and Cygwin. Unless someone tells me otherwise?

I _think_ the culprit was an unnecessary "sudo" or maybe a missing chown/chgrp command somewhere that caused some of the simple but irritating permissions problems?

This problem doesn't show up on Cygwin, as Cygwin doesn't have sudo or root users.

But UWin, it would/could be a problem. Can someone point me to where the problem might be in my originating post? I'm quickly reviewing that post, and just don't see where the problem might be...

Apologies, all, for being silent for a few weeks. This is an insanely busy time for me in all my businesses. None are retail/X-mas affected, per-se!

I'll readily / happily edit my instructions if an inadvertent/unnecessary "sudo" needs to be corrected somewhere.

Can someone let me know if/what changes I may need to make to the original post?

It may be that you need to execute:

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

to create the "adtools" symlink only after the toolchain build process has completed; just to ensure the top-level adtools-ppc-... directory has been created.

Slightly different thoughts....try any or all of them.

1) It may be that you've got a dead/missing symlink in your /usr/local/amiga directory. As in, you might be missing the "/usr/local/amiga/adtools" symlink that some things rely upon in the build instructions. Start with confirming/creating the symlink. If it's not there, "sudo ln -s /usr/local/amiga/adtools-ppc-uwin64-20170623-404 /usr/local/amiga/adtools"

2) I've still not tried to do the compilation of the SDL toolkit, but I wonder aloud what might happen if you replace just the UWin gcc executable in its normal /usr/bin/gcc location with a symlink from:

/usr/bin/gcc -> /usr/local/amiga/adtools/bin/ppc-amigaos-gcc

Then:

gcc -v

If that gcc command actually now calls the ppc-amigaos-gcc executable, how does your SDL build behave?



3) Do you have another Windows PC? Or even a VirtualBox clean Windows image you could use to try with some clean slate?

I'm entirely unfamiliar with SDL.

If anyone can inform me what they're trying to compile/build, the sources for same (I just downloaded a couple of .lha's, one called SDL2_SDK_r177.lha and another SDL2_user_r177.lha. Not sure if that's even what I'm looking for.

I don't even know what a "hello, world" looks like with this library/toolkit. If someone can provide that, too, so I can confirm things are working that'd be hugely helpful.

Basically, I don't know anything about it, so I just need a starting point to see if I can get things to compile/build/Hello World. If I can, I'll report back on what I find.

Sorry folks. Been swamped, and will be some more, for remainder of the year.

I'll try to answer everyone's questions shortly.

And, yes, building a download repo for all the pre-built binaries was always my intention. These posts are just to explain everything I learned for my own (and all future developers' sakes).

For ease of reference, in case you're one of those readers who, like me, tend to just hop to the end of a long topic chain to see where everything has landed:


The first/originating post in this topic chain has now been extensively updated again. Most of the typos/errors/clarifications should be in there.

I also have 2 follow-on guides to this one.

1st: A guide showing how to actually use the Cygwin version of these adtools inside Visual Studio 2017

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


2nd: A guide showing how to actually use either the Cygwin or UWin versions of these adtools from your Cygwin or UWin bash command-lines instead of using an IDE.

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

For all those who've been reading this, I've now completed the first draft with edits to my original post.

And, again, I've done a few changes. This time to the instructions on how to add multiple Include and Library search paths to your makefile.

Using the Cygwin/Bash on Ubuntu on Windows (UWin) Command Line to Cross-Compile PowerPC (ppc) Amiga OS4 Code via the Built-from-Source Cygwin-hosted or UWin-hosted adtools (cyg-adtools/uwin-adtools) Toolchain

[First Published 2017-10-21]


[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) The post you're reading now, 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) A post 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) ]


Pre-Requisites:




This guide is intended to pick up where my prior guide left off, wherein I showed how to use Cygwin64 as a host environment to build from source, and run, the latest Windows-based / Cygwin-based Amiga Developer Tools (cyg-adtools) toolchain capable of generating ppc AmigaOS/OS4 binaries from a Windows 10 developer workstation.

Although I've only tested these instructions on the Cygwin environment with my cyg-adtools toolchain, they _should_ work unaltered with the uwin-adtools toolchain (also from my prior guide) except where noted below.

These instructions should also work with Linux and Mac adtools toolchains, although my prior guide only alludes to, and doesn't fully describe, how to build the adtools cross-compiling toolchains from source.

If you do manage to get mac/lin-adtools built, the instructions in this guide should work with only trivial changes.

Likewise, given how close Cygwin/UWin are to Linux/Macports, my prior guide showing how to build a cyg-adtools and uwin-adtools toolchain from source should also be _very_ close to what's needed for Linux and Mac.

The prior guide (aka "original guide" or "originating guide") I keep alluding to throughout this guide is a prerequisite for this guide, and it can be found at:

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

That is, this guide is intended to show how to actually _use_ the cyg-adtools/uwin-adtools toolchain with your own or some 3rd party's headers/libraries, because the example programs from my original guide ("Hello, World" and "easy") aren't all that useful in and of themselves. Those examples do prove, however, that everything works perfectly with the adtools setup, as described.

In essence, this guide intends to show how to include any OS4.x, arbitrary 3rd party, or your own, code with headers and libraries for use by your cyg/uwin-adtools toolchain. You'll need only your cyg/uwin-adtools toolchain, your Cygwin/UWin bash shell, plus your favourite Windows-based text/programmer's editor.

By way of context, this guide is really just a very specific/particular application of the general knowledge needed to get gcc/g++ working as you'd like. I am simply modifying the standard gcc/g++ instructions, and tweaking them to account for the AmigaOS cross-compiling adtools-specific configurations as baked-in by the built-from-source adtools chain (assuming you've followed my originating adtools post without modification).

Lastly, like all my guides, this is lengthy. Really lengthy. But only because I'm trying to impart knowledge that, once imparted, it takes mere seconds to use subsequently.


A little backgrounder:

In my originating guide, aside from the fact that you're able to create an Amiga OS4 executable from within a truly up-to-date/modern gcc/g++ environment running on a Windows machine (which is awesome), the "Hello World" tests I show don't actually call any Amiga-specific functions or use any Amiga-specific libraries/headers like any real program/library needs to do.

That's what my "easy" test showed -- but, even though the "easy" build test _absolutely_ proves you're successfully cross-compiling/linking Amiga-specific headers/libs using your Windows Cygwin/Uwin development environment -- it's not necessarily obvious how all this is working or how you'd use all these adtools yourself for your own code, or 3rd party Amiga code.

As in, how do the cyg/uwin-adtools' ppc-amigaos-gcc/g++ commands, as seen in my original guide's "Hello, World" and "easy" examples, actually work?

Well, if you've followed all of my original guide's instructions, whether in Cygwin or Uwin, then all the cross-compiling/building tools are found in your Cygwin/Uwin's "/usr/local/amiga/adtools-<xyz_version>" directory and below; and if you've really followed my instructions, you have a symbolic link "/usr/local/amiga/adtools" that can point to whatever version of the adtools you've built from source.

With that in mind, let's dive in to things...


How-To:

If you'd like a very slick IDE setup instead of using the command line, see my other guide on how to integrate your cyg/uwin-adtools toolchain with the Microsoft Visual Studio 2017 IDE:
http://www.amigans.net/modules/xforum ... 9&forum=25&post_id=108233

By contrast, this guide is for all the command-line warriors out there, like me, who quite prefer life outside an IDE. For you, there are basically 2 ways to use your cyg/uwin-adtools toolchain.

You can either:

a) use command-line switches, where you

i) pass-in to ppc-amigaos-gcc/g++/ld, all the compiler parameters needed such as Include and Library search paths, or

ii) use environment variables to tell ppc-amigaos-gcc/g++/ld what Include and Library search paths to use, or


b) use "make" files to tell ppc-amigaos-gcc/g++/ld the Include and Library search paths that you'd like to use.

In this guide I'll show very basic examples of (a)(i), (a)(ii), and (b).


Also, note that although I've written this guide for the cyg-adtools toolchain only (because I personally only use Cygwin myself and not UWin), but for the uwin-adtools users, simply substitute "uwin64" whenever you see "cyg64".


Includes/Headers -- The gcc/g++ Include Search Paths

To identify the built-in Include search path used by your adtools, you can execute both of these commands (without the quotes):

"echo | ppc-amigaos-gcc -E -Wp,-v -"

This will show the default Include search path being used by the adtools' gcc command.

Similarly, execute:

"echo | ppc-amigaos-g++ -E -Wp,-v -"

Which will show the adtools' g++ default Include search path.


If you compare those 2 commands' output, you'll note that both ppc-amigaos-gcc and ppc-amigaos-g++ share the following search paths:

"/usr/local/amiga/adtools-ppc-cyg64-20170623-404/ppc-amigaos/SDK/newlib/include"
"/usr/local/amiga/adtools-ppc-cyg64-20170623-404/ppc-amigaos/SDK/include/include_h"
"/usr/local/amiga/adtools-ppc-cyg64-20170623-404/ppc-amigaos/SDK/include/netinclude"


Or, for your own convenience, if you've used the symlink I suggested in my original guide:

"/usr/local/amiga/adtools/ppc-amigaos/SDK/newlib/include"
"/usr/local/amiga/adtools/ppc-amigaos/SDK/include/include_h"
"/usr/local/amiga/adtools/ppc-amigaos/SDK/include/netinclude"


These directories are about to become very important....


When you built your cyg/uwin-adtools toolchain from source, its very extensive build scripts baked-in a bunch of default search paths for Includes/header files; those baked-in paths include the ones I just listed above.

To understand how all the pieces fit, look again at the "easy.c" source file in my original guide, or indeed just look at any standard Amiga source file, and you'll see various Amiga-specific #include directives. For example, in "easy.c" you'll find:

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

Now, in your Cygwin/Uwin bash shell, if you look in the "/usr/local/amiga/adtools/ppc-amigaos/SDK/include/include_h" directory, you'll find a subdirectory called "proto" inside which you'll find the "exec.h" and "intuition.h" header files.

So, that's a really long way to say that inside the "/usr/local/amiga/adtools-<xyz version>/ppc-amigaos/SDK/include/include_h" directory or, for convenience, if you've used the adtools symlink I recommended in my original guide, the "/usr/local/amiga/adtools/ppc-amigaos/SDK/include/include_h" directory is where you find all the base OS4.x header files to do standard Amiga OS4 development.

Similarly, by default, if you followed my original post, you'll also find: "/usr/local/amiga/adtools/ppc-amigaos/SDK/clib2/include" directory, and also the "/usr/local/amiga/adtools/ppc-amigaos/SDK/newlib/include" directory which contain the header files for clib2 or newlib respectively.

And, lastly, if you've followed my original post for SDK updates, all these directories should stay intact and should continue to work, even after updating the Amiga OS4 SDK.


Libs: The gcc/g++/ld Library Search Paths

So, we've seen how your adtools gcc/g++'s default Include/header search paths work. What about Library files and the search paths used by the adtools' linker (named "ppc-amigaos-ld") for finding libs to link your code against?

Well, if you run the following command (without the quotes) from your bash shell:

"ppc-amigaos-gcc -print-search-dirs"

You'll see something like:

...
libraries: =/usr/local/amiga/adtools-ppc-cyg64-20170623-404/lib/gcc/ppc-amigaos/5.4.0/:/usr/local/amiga/adtools-ppc-cyg64-20170623-404/lib/gcc/ppc-amigaos/5.4.0/../../../../ppc-amigaos/lib/ppc-amigaos/5.4.0/:/usr/local/amiga/adtools-ppc-cyg64-20170623-404/lib/gcc/ppc-amigaos/5.4.0/../../../../ppc-amigaos/lib/

If you parse-out that output, you'll see:

"/usr/local/amiga/adtools-ppc-cyg64-20170623-404/lib/gcc/ppc-amigaos/5.4.0/../../../../ppc-amigaos/lib/"

Which translates to:

"/usr/local/amiga/adtools-ppc-cyg64-20170623-404/ppc-amigaos/lib"

Or if you have your symlink working:

"/usr/local/amiga/adtools/ppc-amigaos/lib"


Similarly, in that output you'll see:

"/usr/local/amiga/adtools-ppc-cyg64-20170623-404/lib/gcc/ppc-amigaos/5.4.0"

Which, with a symlink, translates to:

"/usr/local/amiga/adtools/lib/gcc/ppc-amigaos/5.4.0"


That is, the 2 major directories used as default lib search directories by the ppc-amigaos-ld linker are:

"/usr/local/amiga/adtools/ppc-amigaos/lib"
"/usr/local/amiga/adtools/lib/gcc/ppc-amigaos/5.4.0"

And all their subdirectories.


What about the other 3rd party/other headers and library files that you'll need to use?

So, we now know where, by default, your ppc-amigaos-gcc/g++ toolchain looks for its headers, which is inside the follow directories and their subdirectories:

"/usr/local/amiga/adtools/ppc-amigaos/SDK/newlib/include"
"/usr/local/amiga/adtools/ppc-amigaos/SDK/include/include_h"
"/usr/local/amiga/adtools/ppc-amigaos/SDK/include/netinclude"

And where your ppc-amigaos-ld linker looks for its libs, which is the following directories and their subdirectories:

"/usr/local/amiga/adtools/ppc-amigaos/lib"
"/usr/local/amiga/adtools/lib/gcc/ppc-amigaos/5.4.0"

That's good to know, and it's good to know that if you update your SDK or update your toolchain from source, all the above will change a little, but if you use/update the "adtools" symlink as instructed in my prior guide, this guide will still work.


What about 3rd party, or your own, headers/libs?

Well, the Amiga gcc/g++ cross toolchains don't actually care where your header/lib files are, so long as they can find, or be told where to find them.

So that means you can simply create subdirectories under the various directories I just listed above, and then copy your new/3rd party headers/libs to those respective subdirs, and call those headers in your #include directives. The ppc-amigaos-gcc/g++/ld commands should find your headers/libs and work -- but that's rather messy and non-standard, and will create more work for you every time you update your AmigaOS SDK.

Much cleaner, much more standard, and far less work after every SDK update is if you put your own/3rd party libraries/headers in some separate directory apart from the standard SDK directory, and then tell the Amiga gcc/g++ toochains where to look for your libs/headers using Cygwin/UWin command-line switches, environment variables, or makefiles.

For the following instructions, let's assume that you've put all your own headers/libs and some 3rd party headers/libs in the following directories:

"/usr/local/amiga/myproj/include"
"/usr/local/amiga/myproj/lib"
"/usr/local/amiga/3rdparty/include"
"/usr/local/amiga/3rdparty/lib"

We'll also assume for the following instructions that your source files "myproj.c" and "myproj.cpp" are in the /usr/local/amiga/myproj/src/ directory. And that each of these source files has all the proper #include directives in them.


Adtools Includes and Libs via Command-Line Switches

In many ways, using command-line switches is the easiest way to accomplish what you're looking to do ... just know that it can create really long commands.

[As a little tip, I like to keep a text editor with the multi-line command typed in -- that's what the backslash is at each line, a bash multi-line command delimiter -- like you see below, so I can simply copy/paste the long command into the bash command line every time I need it. I don't usually create shell scripts for this. If I want something like a shell script, I use the proper tool -- a makefile, as described below.]

For example, to compile your "myproj.c" file with Amiga-friendly debugging symbols inserted, assuming your code, your 3rd party headers and libs, and your own headers and libs are placed as noted above, then you would use the following command (without the quotes):

"ppc-amigaos-gcc -Wall -ggdb -gstabs \
-I /usr/local/amiga/myproj/include \
-I /usr/local/amiga/3rdparty/include \
-L /usr/local/amiga/myproj/lib \
-L /usr/local/amiga/3rdparty/lib \
-o /usr/local/amiga/myproj/myproj /usr/local/amiga/myproj/src/myproj.c"

Similarly, if you wanted to compile your "myproj.cpp" file with debug symbols inserted:

"ppc-amigaos-g++ -Wall -ggdb -gstabs \
-I /usr/local/amiga/myproj/include \
-I /usr/local/amiga/3rdparty/include \
-L /usr/local/amiga/myproj/lib \
-L /usr/local/amiga/3rdparty/lib \
-o /usr/local/amiga/myproj/myproj /usr/local/amiga/myproj/src/myproj.cpp"


Note that both the -I and -L switches simply add to the default/baked-in header/lib directories that we identified previously, meaning you don't have to also set-out where all the standard Amiga SDK libs/headers are.

Lastly, if you want to compile your code _without_ the debug symbols, then just delete the "-ggdb" and "-gstabs" command-line switches.

For more information, see the main authority on the matter, the GCC official documentation, specifically:

https://gcc.gnu.org/onlinedocs/gcc/Dir ... ns.html#Directory-Options

and

https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options



Adtools Includes and Libs via Environment Variables

You can also use bash environment variables to accomplish what you seek.

For example:

LIBRARY_PATH specifies a list of directories to search for libs, as if specified with -L

CPATH specifies a list of directories to be searched as if specified with -I

C_INCLUDE_PATH and CPLUS_INCLUDE_PATH are like CPATH, but for C/C++ specifically, if there's some difference in your headers.


So, mirroring the command-line-switch example above, from your bash shell you'd execute the following commands (without the quotes), and only once per logged in bash session:

"export LIBRARY_PATH=/usr/local/amiga/myproj/lib:/usr/local/amiga/3rdparty/lib"

"export CPATH=/usr/local/amiga/myproj/include:/usr/local/amiga/3rdparty/include"



And, then, every time you want to compile your code (without the quotes):

"ppc-amigaos-gcc -Wall -ggdb -gstabs \
-o /usr/local/amiga/myproj/myproj /usr/local/amiga/myproj/src/myproj.c"

or

"ppc-amigaos-g++ -Wall -ggdb -gstabs \
-o /usr/local/amiga/myproj/myproj /usr/local/amiga/myproj/src/myproj.cpp"

If you want to remove the debug symbols, just omit the "-ggdb" and "-gstabs" command-line switches.

Again, for more information, see the main source for this guide, the GCC official documentation, specifically:

https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html



Adtools Includes and Libs via makefiles

By far, makefiles are the most powerful/flexible/clean way to accomplish your build. But, they're also a bit more work, and the following are only the most stupid/simple examples of a makefile, and also the simplest subsequent use of a makefile, that I could imagine.

There are countless publicly-available resources about GNU makefiles. Use them to your heart's content; just keep these examples in-mind when you do so, really just the "-gdb", "-gstabs" and your own/3rd party header and library search paths.


Step 1: Assuming we're using all the same directories as above, create a makefile, named "makefile" using your favourite editor or just "nano". Save that makefile as "/usr/local/amiga/myproj/src/makefile"

Copy the following contents into the "makefile" file, copying everything between but excluding the quotes. After you do a copy/paste, make sure you actually insert a Tab where I note <put a tab here> and delete the words "<put a tab here>":

"all:
<put a tab here> /usr/local/amiga/adtools/bin/ppc-amigaos-gcc -o /usr/local/amiga/myproj/myproj /usr/local/amiga/myproj/src/myproj.c -Wall -ggdb -gstabs -I/usr/local/amiga/myproj/include -I/usr/local/amiga/3rdparty/include -L/usr/local/amiga/myproj/lib -L/usr/local/amiga/3rdparty/lib

clean:
<put a tab here> rm /usr/local/amiga/myproj/myproj"


Step 2: To build your code, in your bash shell, execute (without the quotes)

"cd /usr/local/amiga/myproj/src"
"make"

That should build your executable, "myproj" and put it in your /usr/local/amiga/myproj directory.

Note that both the -I and -L switches simply add to the default/baked-in header/lib directories that we identified previously, meaning you don't have to also set-out where all the standard Amiga SDK libs/headers are.

Lastly, if you want to compile your code _without_ the debug symbols, then just delete the "-ggdb" and "-gstabs" command-line switches.


Step 3: To re-build your code, you probably want to delete the prior-compiled executable and then compile again.

Execute (without the quotes):

"cd /usr/local/amiga/myproj/src"
"make clean"
"make"





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

@AmigaBlitter:

Not sure what's going on with your setups. It's like the symlinks are all wonky. My output looks like this:


$ ls -hal /usr/local/amiga/
total 5.0K
drwxr-xr-x+ 1 sc None 0 Oct 19 23:23 .
drwxr-xr-x+ 1 sc None 0 Oct 4 05:10 ..
lrwxrwxrwx 1 sc None 47 Oct 5 05:03 adtools -> /usr/local/amiga/adtools-ppc-cyg64-20170623-404
lrwxrwxrwx 1 Administrators None 30 Oct 5 07:26 adtoolsln -> adtools-ppc-cyg64-20170623-404
drwxr-xr-x+ 1 sc None 0 Oct 4 06:59 adtools-ppc-cyg64-20170623-404


Note, the "adtoolsln" is another symlink that was created as part of my Visual Studio 2017 guide. That is, there are 2 symlinks pointing to the same "adtools-ppc-cyg64-20170623-404" directory -- one usable from Cygwin, the other from Windows.

For the purposes of this post, however, I'm not sure what's going on with your build.

And my Cygwin setup was done with the command, as-originally-posted, namely:

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

Or for Uwin:

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


I have a suggestion: redo everything from scratch. That is, follow the instructions from the outset by deleting or renaming the /usr/local/amiga directory and starting from step 1.

I think I've inadvertently caused you some mis-steps in the setup because I've been editing/updating the instructions along the way...and I think you've got a versioning thing going on because of the pathnames/etc I see. Apologies.

FYI, all:

I've been updating my originating post as your comments/error/typo corrections have been coming in, via your replies in this topic thread.

I'll continue to do so whenever I can, so that someone _doesn't_ have to read this entire thread to get things working.

@AmigaBlitter: You (and everyone else) are more than welcome. Happy to help when I can.

I'm thinking there was a symbolic link error somewhere there. Namely, that the symlink "adtools" should point to adtools-ppc-uwin-20170623-404.

If you provide the output of:

"ls -hal /usr/local/amiga"

and also:

"ls -hal /usr/local/amiga/adtools"

and also:

"ls -hal /usr/local/amiga/adtools-ppc-uwin-20170623-404"

That might help to decipher what's happening on your setup.