GCC 6.2 toolchain for AmigaOS 3 - Page 23

bebbo · 16 October 2017, 17:29

Quote:

Originally Posted by MartinW

That's great to hear!

I don't wish to derail things, but what's the current state of play in regard to this on MacOS? I installed a Linux partition on my gaming PC pretty much specifically for this and that's fine, but I'd prefer to get back to my MacBook Air if I could.

AFAIK you should be able to build the toolchain on OSX.

MartinW · 16 October 2017, 17:54

Sorry, my bad. I thought at one point the repo said it didn't work on Mac or at least didn't specifically mention Mac. I may have dreamt that as it certainly does now

alpine9000 · 17 October 2017, 06:51

Quote:

Originally Posted by MartinW

That's great to hear!

I don't wish to derail things, but what's the current state of play in regard to this on MacOS? I installed a Linux partition on my gaming PC pretty much specifically for this and that's fine, but I'd prefer to get back to my MacBook Air if I could.

It should work fine on MacOS. If you are having problems I can help you get it working.

MartinW · 17 October 2017, 23:10

Cheers! I'll have another go soon and let you know. IIRC the build environment should be all ready to just git pull and rebuild. Mostly. Ah, actually maybe not. I have a feeling that might have been on a hackintosh I don't have any more. Hmmm. Will check on the MBA.

MartinW · 18 October 2017, 14:49

I tried to build on MacOS Sierra 10.13 last night. It got a very long way through but ultimately failed:

Code:

In file included from /Users/mart/amigaos-cross-toolchain/submodules/gcc-6/gcc/bbb-opts.c:71:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/set:390:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/functional:1398:2: error: no member named
      'fancy_abort' in namespace 'std::__1'; did you mean simply 'fancy_abort'?
        _VSTD::abort();

Ultimately ending in:

Code:

15 warnings and 11 errors generated.
make[1]: *** [bbb-opts.o] Error 1
make: *** [all-gcc] Error 2
ERROR: command "make all-gcc CFLAGS_FOR_TARGET=-noixemul -Os MAKEINFO=makeinfo -j1" failed with 2
DEBUG: restoring old value of environment variable "CC"
DEBUG: restoring old value of environment variable "CXX"
DEBUG: restoring old value of environment variable "CXXFLAGS"
DEBUG: restoring old value of environment variable "CFLAGS"

As far as I could see all of the errors were the same 'fancy_abort' error. I tried to search google for this and it was difficult to find anything specific but I did see in one conversation where it implied it might be related to the recent release of Xcode 9.

It's worth noting that I haven't specifically checked my dependencies. My way of doing that is a bit hit and miss. I tend to just run the build, if I get a failure it's usually obvious if it's missing a dep so I add it, re-run, repeat until there are no more missing errors. This doesn't look like one of those however.

Just to be sure I did do a clean and fresh build (with rm -if in the .build folder).

bebbo · 18 October 2017, 19:56

Quote:

Originally Posted by Marlon_

Yeah...

Please build milkytracker with the recent version 20171018-194704.

With

Code:

-Os -fno-exceptions -fno-rtti

the size is down to 2295816.

And with the fixed bugs it's maybe working for you too now?

alpine9000 · 19 October 2017, 01:22

Quote:

Originally Posted by MartinW

I tried to build on MacOS Sierra 10.13 last night. It got a very long way through but ultimately failed:

Code:

In file included from /Users/mart/amigaos-cross-toolchain/submodules/gcc-6/gcc/bbb-opts.c:71:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/set:390:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/functional:1398:2: error: no member named
      'fancy_abort' in namespace 'std::__1'; did you mean simply 'fancy_abort'?
        _VSTD::abort();

Ultimately ending in:

Code:

15 warnings and 11 errors generated.
make[1]: *** [bbb-opts.o] Error 1
make: *** [all-gcc] Error 2
ERROR: command "make all-gcc CFLAGS_FOR_TARGET=-noixemul -Os MAKEINFO=makeinfo -j1" failed with 2
DEBUG: restoring old value of environment variable "CC"
DEBUG: restoring old value of environment variable "CXX"
DEBUG: restoring old value of environment variable "CXXFLAGS"
DEBUG: restoring old value of environment variable "CFLAGS"

As far as I could see all of the errors were the same 'fancy_abort' error. I tried to search google for this and it was difficult to find anything specific but I did see in one conversation where it implied it might be related to the recent release of Xcode 9.

It's worth noting that I haven't specifically checked my dependencies. My way of doing that is a bit hit and miss. I tend to just run the build, if I get a failure it's usually obvious if it's missing a dep so I add it, re-run, repeat until there are no more missing errors. This doesn't look like one of those however.

Just to be sure I did do a clean and fresh build (with rm -if in the .build folder).

I looked into this and it seems to be an issue since Xcode9 (I had the same problem since upgrading xcode).

I was able to fix it, and I have sent bebbo a patch. If you're up to patching the gcc source yourself, here is the patch:

Code:

diff --git a/gcc/bbb-opts.c b/gcc/bbb-opts.c
index 99785cf5d6a..162625a4362 100755
--- a/gcc/bbb-opts.c
+++ b/gcc/bbb-opts.c
@@ -53,6 +53,9 @@
  */

 #include "config.h"
+#define INCLUDE_VECTOR
+#define INCLUDE_SET
+#define INCLUDE_MAP
 #include "system.h"
 #include "coretypes.h"
 #include "backend.h"
@@ -67,9 +70,6 @@
 #include "tree-pass.h"
 #include "conditions.h"
 #include "langhooks.h"
-#include <vector>
-#include <set>
-#include <map>

 static int xx = 0;

bebbo · 19 October 2017, 08:10

Quote:

Originally Posted by alpine9000

I looked into this and it seems to be an issue since Xcode9 (I had the same problem since upgrading xcode).

I was able to fix it, and I have sent bebbo a patch. If you're up to patching the gcc source yourself, here is the patch:

Code:

diff --git a/gcc/bbb-opts.c b/gcc/bbb-opts.c
index 99785cf5d6a..162625a4362 100755
--- a/gcc/bbb-opts.c
+++ b/gcc/bbb-opts.c
@@ -53,6 +53,9 @@
  */

 #include "config.h"
+#define INCLUDE_VECTOR
+#define INCLUDE_SET
+#define INCLUDE_MAP
 #include "system.h"
 #include "coretypes.h"
 #include "backend.h"
@@ -67,9 +70,6 @@
 #include "tree-pass.h"
 #include "conditions.h"
 #include "langhooks.h"
-#include <vector>
-#include <set>
-#include <map>

 static int xx = 0;

I understand that it's not working for you. But I don't understand what should be wrong with

Code:

#include <vector>
#include <set>
#include <map>

You could use a working compiler, no?

alpine9000 · 19 October 2017, 09:15

Quote:

Originally Posted by bebbo

I understand that it's not working for you. But I don't understand what should be wrong with

Code:

#include <vector>
#include <set>
#include <map>

You could use a working compiler, no?

Haha yes, but to be fair I think it’s because gcc redefines abort() and this is what causes the issue with the latest Xcode.

pipper · 19 October 2017, 09:23

Hi all,

First of all, awesome work, bringing a more modern C++ compiler to the Amiga :-)

I am currently toying around with it, trying to compile ADoom with it.
ADoom was made for SAS/C, so it has a few constructs like this:

Code:

void __regargs __asm indivision_core(register __a0 ULONG indivisioncpldbase,
                           register __d2 UWORD coreadd);

void __regargs __asm indivision_waitconfigdone(register __a0 ULONG indivisioncpldbase);

ULONG __regargs __asm indivision_checkcore(register __a0 ULONG indivisionfpgabase,
				register __d1 UWORD coreid);

void __regargs __asm indivision_initscreen(register __a0 ULONG indivisionfpgabase,
				 register __d0 UBYTE screenmode);

void __regargs __asm indivision_gfxcopy (register __a0 ULONG indivisionfpgabase,
                               register __a2 UBYTE *chunky_data,
                               register __a3 long *palette_data,
                               register __d0 ULONG gfxaddr,
                               register __d1 ULONG size);

What would be the best way to translate such function declarations to gcc (i.e. passing specific function parameters in specific registers).

Thanks a bunch!

MartinW · 19 October 2017, 12:56

Quote:

Originally Posted by bebbo

You could use a working compiler, no?

Genuine question - how would I do that? When I looked all bins for stuff like compilers were soft links to clang. It's pretty well embedded on MacOS.

I applied the patch and it got around that problem but I still have a problem further down. On one of the libraries (libm5.4 maybe? something like that) configure fails when it checks to see if the m68k version of gcc can compile and it dies and simply says no.

I didn't investigated further as it was 2:30AM and the battery was virtually out.

alpine9000 · 19 October 2017, 13:09

Quote:

Originally Posted by MartinW

Genuine question - how would I do that? When I looked all bins for stuff like compilers were soft links to clang. It's pretty well embedded on MacOS.

I applied the patch and it got around that problem but I still have a problem further down. On one of the libraries (libm5.4 maybe? something like that) configure fails when it checks to see if the m68k version of gcc can compile and it dies and simply says no.

I didn't investigated further as it was 2:30AM and the battery was virtually out.

I’ll try and build the full tool chain with Xcode9 tomorrow, hopefully it’s an easy fix.

MartinW · 19 October 2017, 13:18

Thank you - your help is appreciated. Don't overlook that I could be missing something or indeed doing something stupid.

bebbo · 19 October 2017, 21:56

Quote:

Originally Posted by pipper

Hi all,

First of all, awesome work, bringing a more modern C++ compiler to the Amiga :-)

I am currently toying around with it, trying to compile ADoom with it.
ADoom was made for SAS/C, so it has a few constructs like this:

Code:

void __regargs __asm indivision_core(register __a0 ULONG indivisioncpldbase,
                           register __d2 UWORD coreadd);

void __regargs __asm indivision_waitconfigdone(register __a0 ULONG indivisioncpldbase);

ULONG __regargs __asm indivision_checkcore(register __a0 ULONG indivisionfpgabase,
                register __d1 UWORD coreid);

void __regargs __asm indivision_initscreen(register __a0 ULONG indivisionfpgabase,
                 register __d0 UBYTE screenmode);

void __regargs __asm indivision_gfxcopy (register __a0 ULONG indivisionfpgabase,
                               register __a2 UBYTE *chunky_data,
                               register __a3 long *palette_data,
                               register __d0 ULONG gfxaddr,
                               register __d1 ULONG size);

What would be the best way to translate such function declarations to gcc (i.e. passing specific function parameters in specific registers).

Thanks a bunch!

Code:

int foo2(register int x asm("d0")) {
  return x + x;
}

yields

Code:

_foo2:
        add.l d0,d0
        rts

I'm using a set of macros:

Code:

#if defined(NOASM)
#define ASM
#define RD0(r) r
#define RD1(r) r
...
#elif defined(__GNUC__)
#define ASM
#define RD0(r) register r __asm("d0")
#define RD1(r) register r __asm("d1")
...
#elif defined(__VBCC__)
#define ASM
#define RD0(a) register __reg("d0") a
#define RD1(a) register __reg("d1") a
...
#else // SAS/C
#define ASM __asm
#define RD0(a) register __d0 a
#define RD1(a) register __d1 a
...
#endif

...

int ASM foo2(RD0(int x)) {
  return x+x;
}

pipper · 22 October 2017, 00:13

I got a little further now.
Unfortunately, I'm running into multiple internal compiler errors. All seem to revolve around the handling of non-function local variables (globals).

One issue that puzzles me now is how to let vasm produce object files that gcc can link against?!

alpine9000 · 22 October 2017, 03:16

Quote:

Originally Posted by MartinW

Genuine question - how would I do that? When I looked all bins for stuff like compilers were soft links to clang. It's pretty well embedded on MacOS.

I applied the patch and it got around that problem but I still have a problem further down. On one of the libraries (libm5.4 maybe? something like that) configure fails when it checks to see if the m68k version of gcc can compile and it dies and simply says no.

I didn't investigated further as it was 2:30AM and the battery was virtually out.

I can see why this fails. The libnix build deletes a bunch of files then re-creates them, but on OSX this fails due to awk complaining of "too many files open" or some such. I am not sure if these files 100% need to be regenerated to get a working build. I was able to hack it to get past this step by just commenting out this step in submodules/libnix:

Note: if the files have already been deleted, you can get them back by running "git checkout -- ." in submodules/libnix.

Code:

diff --git a/sources/Makefile.in b/sources/Makefile.in
index ff0853b..76c1742 100644
--- a/sources/Makefile.in
+++ b/sources/Makefile.in
@@ -68,17 +68,17 @@ $(FLDIR)/filelist:
 
 # build stubs for library base pointers
 libbases/dos.c: $(STUBDIR)/Makefile library.list
-       -rm -f libbases/* libnames/*
-       $(AWK) <library.list '{ sname=substr($$2,1,length($$2)-8);        \
-         fname="libbases/" sname ".c";                      \
-         print "/* Machine-generated C-file- do not edit ! */" >fname; \
-         print "#include <stabs.h>"                            >fname; \
-         print "extern char __" sname "name[];"                >fname; \
-         print "void *" $$1 "[2]={ 0l,__" sname "name };"      >fname; \
-         print "ADD2LIB(" $$1 ");"                             >fname; \
-         fname="libnames/" sname ".c";                      \
-         print "/* Machine-generated C-file- do not edit ! */" >fname; \
-         print "char __" sname "name[]=\"" $$2 "\";"           >fname;}'
+       #-rm -f libbases/* libnames/*
+       #$(AWK) <library.list '{ sname=substr($$2,1,length($$2)-8);        \
+       #  fname="libbases/" sname ".c";                      \
+       #  print "/* Machine-generated C-file- do not edit ! */" >fname; \
+       #  print "#include <stabs.h>"                            >fname; \
+       #  print "extern char __" sname "name[];"                >fname; \
+       #  print "void *" $$1 "[2]={ 0l,__" sname "name };"      >fname; \
+       #  print "ADD2LIB(" $$1 ");"                             >fname; \
+       #  fname="libnames/" sname ".c";                      \
+       #  print "/* Machine-generated C-file- do not edit ! */" >fname; \
+       #  print "char __" sname "name[]=\"" $$2 "\";"           >fname;}'

pipper · 22 October 2017, 09:40

Quote:

Originally Posted by pipper

One issue that puzzles me now is how to let vasm produce object files that gcc can link against?!

Solved that problem with the -Faout vasm option.

bebbo · 22 October 2017, 10:42

Quote:

Originally Posted by alpine9000

I can see why this fails. The libnix build deletes a bunch of files then re-creates them, but on OSX this fails due to awk complaining of "too many files open" or some such. ...

Ok, you need a working compiler plus a working operating system^^

:-)

guy lateur · 25 October 2017, 14:23

It's been a while since I checked out this wonderful project, and I was wondering what the status of C++ support is at this time.

I mean, do we have:
1) inheritance
2) abstract base classes
3) method overloading
4) operator overloading
5) exceptions
6) templates
7) anything else worth noting

TIA for bringing me up to speed!

bebbo · 25 October 2017, 19:06

Quote:

Originally Posted by guy lateur

It's been a while since I checked out this wonderful project, and I was wondering what the status of C++ support is at this time.

I mean, do we have:
1) inheritance
2) abstract base classes
3) method overloading
4) operator overloading
5) exceptions
6) templates
7) anything else worth noting

TIA for bringing me up to speed!

8) lambda expressions
9) ...

We need YOU to test all this plus everything else

18 October 2017, 14:49	#445
MartinW Registered User Join Date: Mar 2017 Location: Minehead / UK Posts: 608	I tried to build on MacOS Sierra 10.13 last night. It got a very long way through but ultimately failed: Code: In file included from /Users/mart/amigaos-cross-toolchain/submodules/gcc-6/gcc/bbb-opts.c:71: In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/set:390: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/functional:1398:2: error: no member named 'fancy_abort' in namespace 'std::__1'; did you mean simply 'fancy_abort'? _VSTD::abort(); Ultimately ending in: Code: 15 warnings and 11 errors generated. make[1]: * [bbb-opts.o] Error 1 make: * [all-gcc] Error 2 ERROR: command "make all-gcc CFLAGS_FOR_TARGET=-noixemul -Os MAKEINFO=makeinfo -j1" failed with 2 DEBUG: restoring old value of environment variable "CC" DEBUG: restoring old value of environment variable "CXX" DEBUG: restoring old value of environment variable "CXXFLAGS" DEBUG: restoring old value of environment variable "CFLAGS" As far as I could see all of the errors were the same 'fancy_abort' error. I tried to search google for this and it was difficult to find anything specific but I did see in one conversation where it implied it might be related to the recent release of Xcode 9. It's worth noting that I haven't specifically checked my dependencies. My way of doing that is a bit hit and miss. I tend to just run the build, if I get a failure it's usually obvious if it's missing a dep so I add it, re-run, repeat until there are no more missing errors. This doesn't look like one of those however. Just to be sure I did do a clean and fresh build (with rm -if in the .build folder).

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
New GCC based dev toolchain for AmigaOS 3.x	cla	Coders. Releases	8	24 December 2017 10:18
Issue with photon/xxxx WinUAE Toolchain	arpz	Coders. Asm / Hardware	2	26 September 2015 22:33
New 68k gcc toolchain	arti	Coders. C/C++	17	31 July 2015 03:59
Hannibal's WinUAE Demo Toolchain 5	Bobic	Amiga scene	1	23 July 2015 21:04
From gcc to vbcc.	Cowcat	Coders. General	9	06 June 2014 14:45

16 October 2017, 17:54	#442
MartinW Registered User Join Date: Mar 2017 Location: Minehead / UK Posts: 608	Sorry, my bad. I thought at one point the repo said it didn't work on Mac or at least didn't specifically mention Mac. I may have dreamt that as it certainly does now

17 October 2017, 23:10	#444
MartinW Registered User Join Date: Mar 2017 Location: Minehead / UK Posts: 608	Cheers! I'll have another go soon and let you know. IIRC the build environment should be all ready to just git pull and rebuild. Mostly. Ah, actually maybe not. I have a feeling that might have been on a hackintosh I don't have any more. Hmmm. Will check on the MBA.

19 October 2017, 13:18	#453
MartinW Registered User Join Date: Mar 2017 Location: Minehead / UK Posts: 608	Thank you - your help is appreciated. Don't overlook that I could be missing something or indeed doing something stupid.

22 October 2017, 00:13	#455
pipper Registered User Join Date: Jul 2017 Location: San Jose Posts: 652	I got a little further now. Unfortunately, I'm running into multiple internal compiler errors. All seem to revolve around the handling of non-function local variables (globals). One issue that puzzles me now is how to let vasm produce object files that gcc can link against?!

25 October 2017, 14:23	#459
guy lateur Registered User Join Date: May 2017 Location: Belgium Age: 50 Posts: 334	It's been a while since I checked out this wonderful project, and I was wondering what the status of C++ support is at this time. I mean, do we have: 1) inheritance 2) abstract base classes 3) method overloading 4) operator overloading 5) exceptions 6) templates 7) anything else worth noting TIA for bringing me up to speed!

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)