Ok, there you go. I just pushed it :-)

Happy testing!

PS: m68k-amigaos-gcc --help=target (and excuse the bad formatting...)

@matthey

amidevcpp looks like an easy entry but is actually handicap i think. its better to use shell, configure and make and edit the sources respectively.

with amidevcpp you have to build its own custom makefiles, practically regenrating the project which potentially leads to a mess in dependencies and the result isnt portable anymore. i think i wouldnt use devcpp today anymore.

I am using Eclipse for Amiga C/C++ development. I only miss the debugging feature. Hm, maybe remote gdb over telnet...? Hm... :-)

I use the shell for GCC and vbcc projects on the Amiga but it is easy to use. Unix derivatives have a more powerful shell (which is less friendly). Windows has ... neither but it does have some nice text editors.

Novacoder and lantus360 successfully built some large projects and it was their choice of a development environment so I don't think it is bad. Perhaps there were not many easy choices though. It would be good to have more choices of easy to install development environments for the Amiga. Amiga development needs to be easier to encourage it. Sadly, most Amiga hardware is inadequate (too slow, not enough memory, etc.) or too expensive to develop natively on.

I thought it would be fun to develop on my A2000 but quickly figured out that it's just not going to happen with an 030 and 16MB of RAM. I still use it for remote debugging and when I want to play in ASM-One but C happens on my PC with WinUAE.

GCC 6 does look like it's going to be useful for my other project at the moment which is homebrew for a 68K-based arcade system. I'm doing it with GCC 4.3 (I think?) at the moment. I couldn't get Newlib to compile with it - I'll see if I can get 6 to cooperate.

Where does one find the LHa unpacker for Python 2.7? I tried building it on my AMD64 Debian Jessie box but it couldn't unpack most of the packages.

since gdb works well with aros i tried to use it with binaries generated for amiga-m68k target (while keeping them in elf format), which i accidentally got one or another time some feedback from, but couldnt figure it out reliably, neither via tcp localhost nor via console. it shouldnt be so hard, and there are some instructions, on how to do this on the web, but generating bins with debug symbols have been broken lately and still..

i find both shell and editors in linux completely up to the task. i even switched to lubuntu, for ubuntu has been too bloated for me and have to live now with a console that does only have simple scrollback clearing and and and a very basic text editor without highlighting, and it bothers me so little that i didnt even care to look for better replacements.

everybody may prefer a different method. i actually like to make as slight changes to the sources as possible, to either be able to update them to a new revision or even push the changes and have them accepted upstream. not that im doing it, but the option is good to have. devcpp is too hacky to me. and too buggy. it always tried to compile c as c++or vice versa afair. a lot of stuff didnt work and you had to know that it is broken, while there were too few people to tell you all this. i think today its even worse.

i really think we need to stick to cross compilers for now. may be that on aros the substantial part of the toolchain will work natively soon. i had a hint lately but being busy elsewhere have not checked that out. you might well be able to compile aros-68k binaries with gcc6 on an amiga already, im not sure.

I also enjoy the simplicity of the unix shell. Personally I prefer tcsh and nano for these kinds of tasks. But for code editing I use Visual Studio Code. Its not bloated but it still offers the features of a desktop environment. It also eases code navigation and it has IntelliSense(tm). If you don't like Microsoft for some reason, try atom.io instead. It really does make a difference. :spin

Responding to myself: https://github.com/FrodeSolheim/python-lhafile

EDIT

Ha! Figured it out! The "build" subcommand would have taken care of them itself if I had run it with the "./scriptname" instead of "python scriptname". I just had to make a link called python27 that would link back to python.

EDIT2

Ok now I have a real issue in the downloaded cross-toolchain after it built. When including sdtddef.h in an ANSI C source it generates a conflict of two typedefs for wchar_t. One for GCC's headers and another for the system headers.

Is there a define macro that I am supposed to instantiate to prevent one of the definitions of wide characters?

Just read through this interesting thread. I've quite literally this week been playing with VBCC and the cahirwpz gcc toolchain (I had not seen this thread). I'll start a separate thread since I have some questions that are too general for here but I just thought I'd add...

I just built a fresh install of macOS Sierra and decided I'd try to cross compile instead of using SAS/C on my non-RTG A1200. I have JetBrains CLion which uses CMAKE. I could of course use VSCode or Sublime Text 3 but since I have a JetBrains subscription I figured I may as well give the modern IDE a shot.

In short, I couldn't get CLion / CMake to play nicely with VBCC but it seemed to work well enough with the version of GCC that I compiled. As far as my simple tests went. Full code inspection and intelligence for Amiga libs. Very nice.

I didn't do anything special about 32bit gcc so I expect my install is flawed but a simple MUI hello world worked OK.

So, I did some more building of this the other night. I'm on OS X. If I build with --m32 then the build fails. I assume this is why it says it is currently broken on MacOS?

If however I just build (without --m32) then the build completes OK and a simple intuition based Hello World builds and runs fine on FS-UAE.

Can I assume from the latter that everything is OK and I am good to go? Or does my simple example program not scratch the surface enough to hit the reason that this is currently marked as broken on Mac? I am unlikely to be getting anywhere near the level of complexity demonstrated in this thread and will be just doing simple stuff for now.

Thanks.

Should work fine in 64bit mode in OSX.

Thank you - I'm a little bit confused about the difference though.

If it will work fine in 64bit mode, why have the 32bit mode? What is the difference? Obviously I know what 64bit is, and what 32bit is. Since the 68k Amiga is not 64bit, is GCC outputting 32bit binaries regardless of the mode?

Sorry if that's a bit of a noob / obvious question!

Yes it's if gcc and binutils are built as 32bit or 64bit binaries. I think there were historically problems with building older versions of binutils as 64bit (maybe gcc also), and so that's why 32 bit builds are sometimes required.

I am unsure if binutils (assembler/linker) works perfectly on OSX with 64 bit because I use a different set of tools, but gcc works fine.

I would say just go for it and just report any issues you find. Sounds like the basics are working though?

Indeed, the basics seem to be fine. I'm using Jetbrains Clion IDE with a CMake script and I haven't really paid much attention to what the output window says it's doing / using. Maybe I should pay more attention :)

Thanks for the explanation. I'll report back if I get stuck.

Just pushed an update with plenty fixes and some improvements.

Big, big, biiiiiiiiig thanks to alpine9000 who did lot's of testing, bug finding and test case building.

That's more than 5% gain!

I have ideas for further otimizations in my pockets, and I'm open for suggestions (little effort -> huge effect)

I can confirm that this compiler keeps generating faster and faster code each release. I am working on a couple of games, and I have seen similar gains to those bebbo got with tscp.

Really great reat work bebbo, this is such an important project to keep the classic Amiga scene moving forward.

Thanks for all your work!