GCC 6.2 toolchain for AmigaOS 3

[bebbo]

Well - I still recommend using Cygwin 32 bit. It's well known to work.

[guy lateur]

Alright, I seem to have succeeded in building it in 64bit mode, woohoo! I'm not sure everything's ok, though; how can I check?

I know what you said about 32bit being a lot more advisable, but I'm just trying to give/get some feedback about 64bit compilation, right now..

[guy lateur]

Alright, I'm back with some more feedback/questions on the 64bit toolchain. If people want me to stop doing this, just let me know. I'll probably be going the 32bit route after this, anyway..

I've been buiding the examples. In order for this to work, I had to change the first 2 lines of the makefile, to include the path and the .exe extension. It might make more sense to rename the executables and to set the path, but here we are. I have this:

CC = /opt/m68k-amigaos/bin/m68k-amigaos-gcc.exe -g
CXX = /opt/m68k-amigaos/bin/m68k-amigaos-g++.exe -g

I can compile all of the hello-world examples, except hello-iostream, which gives this:

$ /bin/make hello-iostream
/opt/m68k-amigaos/bin/m68k-amigaos-g++.exe -g -noixemul -m68020 -Os -Wall -fomit-frame-pointer -o hello-iostream hello-iostream.cpp -Xlinker --allow-multiple-definition
/opt/m68k-amigaos/lib/gcc/m68k-amigaos/6.3.1b/libstdc++.a(c++locale.o)(.text+0x37e): In function `void std::__convert_to_v<long double>(char const*, long double&, std::_Ios_Iostate&, int* const&)':
/home/guy/amigaos-cross-toolchain/.build-m68k/build/gcc-6/m68k-amigaos/libstdc++-v3/src/c++98/c++locale.cc:203: undefined reference to `__gtxf2'
/opt/m68k-amigaos/lib/gcc/m68k-amigaos/6.3.1b/libstdc++.a(c++locale.o)(.text+0x436):/home/guy/amigaos-cross-toolchain/.build-m68k/build/gcc-6/m68k-amigaos/libstdc++-v3/src/c++98/c++locale.cc:203: undefined reference to `__ltxf2'
/opt/m68k-amigaos/lib/gcc/m68k-amigaos/6.3.1b/libstdc++.a(ctype_configure_char.o)(.text+0x7a): In function `std::ctype<char>::ctype(int*, char const*, bool, unsigned long)':
/home/guy/amigaos-cross-toolchain/.build-m68k/build/gcc-6/m68k-amigaos/libstdc++-v3/src/c++11/ctype_configure_char.cc:49: undefined reference to `vtable for std::ctype<char>'
/opt/m68k-amigaos/lib/gcc/m68k-amigaos/6.3.1b/libstdc++.a(ctype_configure_char.o)(.text+0x18a): In function `std::ctype<char>::ctype(char const*, bool, unsigned long)':
/home/guy/amigaos-cross-toolchain/.build-m68k/build/gcc-6/m68k-amigaos/libstdc++-v3/src/c++11/ctype_configure_char.cc:60: undefined reference to `vtable for std::ctype<char>'
/opt/m68k-amigaos/lib/gcc/m68k-amigaos/6.3.1b/libstdc++.a(basic_file.o)(.text+0x41c): In function `std::__basic_file<char>::showmanyc()':
/home/guy/amigaos-cross-toolchain/.build-m68k/build/gcc-6/m68k-amigaos/libstdc++-v3/src/c++98/basic_file.cc:342: undefined reference to `ioctl'
collect2: fout: ld gaf exit-status 1 terug
make: *** [Makefile:33: hello-iostream] Fout 1

I'm testing this from the shell, on an A1200 (68EC030 @ 50 Mhz, ROM 3.X). Only 2 of the 6 hello-world examples actually work: hello-ks13 and hello-stdio-nix13. Both hello-ks20 and hello-ks20-clib2 give a program failure (error #8000 000B). Hello-stdio-clib2 gives error #8000 0004, and hello-stdio just keeps printing infinite lines of h's (!).

Test-ctors seems to work, though..

[guy lateur]

Ok, I did the same exercise using the 32bit environment. The results are a lot better, as I now have 6 examples running:
hello-ks13
hello-ks20
hello-ks20.clib2
hello-stdio.clib2
hello-stdio.nix13
test-ctors

I have 2 more examples that compile (with warnings), but don't run properly:
hello-mui just hangs
hello-stdio says 'file is not executable'
If I try to run them from the workbench, I just get a hex multiview of the file.

Any tips, anyone? TIA!

[bebbo]

please check the recent update.

hello-mui does only create a funny requester - I'm not looking into mui stuff atm.
hello-iostream still does not link.

also catching exceptions seems not to work.

Using c++ without exceptions seems to work.

[guy lateur]

Originally Posted by bebbo

please check the recent update.

It gives the exact same results. So hello-stdio is still not executable. I'll leave the mui example out of the tests from now on.

Also, I can't build the test-mmu example, not having mmu/descriptor.h available. Is this example still supported? If so, what would be the proper way to add these mmu libraries? Is it a package, or an SDK, or still something else? Sorry, I'm still very new to all this..

Another question: I'm assuming that the build process (takes about 1 hour) would let me know if there were any errors right at the end. I mean, I don't check the complete output, but I'd want to make sure there were no errors. Is the above assumption correct? Because I don't want to run this (time consuming) build process a second time (as suggested in the readme) if I'm not absolutely sure there were errors.

Originally Posted by bebbo

Using c++ without exceptions seems to work.

Well, who needs exceptions anyway, right?

[nogginthenog]

Originally Posted by guy lateur

Another question: I'm assuming that the build process (takes about 1 hour)

In my experience CygWin is a bit slow.

Do you have any Linux experience? My Linux virtual machine running on Windows builds GCC in 23 minutes. I have an older I7 with SSD.

I wouldn't worry too much about c++ on the Amiga. Not much Amiga software is written in it.

[guy lateur]

Originally Posted by nogginthenog

Do you have any Linux experience? My Linux virtual machine running on Windows builds GCC in 23 minutes. I have an older I7 with SSD.

I actually do have some Linux experience, and I've been contemplating installing it just to do this. It's definitely an option.

Originally Posted by nogginthenog

I wouldn't worry too much about c++ on the Amiga. Not much Amiga software is written in it.

Well I'll be trying to write some software myself, so being able to do that in C++ would be nice. I can live with C, though, no problem.

[bebbo]

Originally Posted by guy lateur

It gives the exact same results. So hello-stdio is still not executable. I'll leave the mui example out of the tests from now on.

Some examples are compiled for 68020 - those won't run on 68000.

Also, I can't build the test-mmu example, not having mmu/descriptor.h available. Is this example still supported? If so, what would be the proper way to add these mmu libraries? Is it a package, or an SDK, or still something else? Sorry, I'm still very new to all this..

run

./toolchain-m68k test

then also the mmu stuff is downloaded and installed

Another question: I'm assuming that the build process (takes about 1 hour) would let me know if there were any errors right at the end. I mean, I don't check the complete output, but I'd want to make sure there were no errors. Is the above assumption correct? Because I don't want to run this (time consuming) build process a second time (as suggested in the readme) if I'm not absolutely sure there were errors.

How many threads are you using? You should use all cpu cores, e.g.

./toolchain-m68k build --threads=8

is using up to 8 cores.

And as written I am usually building with

./toolchain-m68k build --threads=8 |& tee b.log

so I could look into the log file.

If the build runs through, there are no errors you could fix (maybe you could, no offence), first you should report those errors.

Well, who needs exceptions anyway, right?

Can be useful, but you can live without that in regard of the bloated code size. Omitting unused features with -fno-exceptions -fno-rtti reduces the code size.

[guy lateur]

Originally Posted by bebbo

Some examples are compiled for 68020 - those won't run on 68000.

I'm testing on an accelerated A1200 (68EC030 @ 50 Mhz, ROM 3.X), should they run on that? And/or can I compile specifically for 68030?

Originally Posted by bebbo

How many threads are you using? You should use all cpu cores

Yes, I was already doing it on 8 threads. It takes 1 hour and 15 minutes to build on my 6-core/12-thread i7-3930K @ 3.2 GHz. I'm not sure processing power is the issue here, but maybe disk access is? Maybe I should consider moving this to an SSD. Or maybe turning off logging to the console might help.

FYI, here are some screenshots from task manager while building. Most of the time, it looked like this (although it dropped down to about 2% regularly):

Sometimes (very rarely) (I think while compiling), it went all out and looked like this:


I'll probably do some more testing later today. Meanwhile, here's my build log for you all to enjoy :
buildLog.zip
I don't think there are any errors in it.

Originally Posted by bebbo

If the build runs through, there are no errors you could fix (maybe you could, no offence)

None taken, I almost certainly couldn't!

[bebbo]

Originally Posted by guy lateur

I'm testing on an accelerated A1200 (68EC030 @ 50 Mhz, ROM 3.X), should they run on that? And/or can I compile specifically for 68030?

I'm testing with 68k und 68020 - all ok here... hm should start my A3000 again ;-)

Originally Posted by guy lateur

Yes, I was already doing it on 8 threads. It takes 1 hour and 15 minutes to build on my 6-core/12-thread i7-3930K @ 3.2 GHz. I'm not sure processing power is the issue here, but maybe disk access is? Maybe I should consider moving this to an SSD. Or maybe turning off logging to the console might help.

SSD - SSD - SSD - SSD - SSD - SSD!!!!!!!11!1!1elf!1!!!!

[Leffmann]

Originally Posted by guy lateur

Yes, I was already doing it on 8 threads. It takes 1 hour and 15 minutes to build on my 6-core/12-thread i7-3930K @ 3.2 GHz. I'm not sure processing power is the issue here, but maybe disk access is? Maybe I should consider moving this to an SSD. Or maybe turning off logging to the console might help.

Use a RAM-drive for things like this, both for speed and to spare your SSD. I can clone, download, and build in less than an hour on an 8-year old laptop with 2 threads, thanks to the RAM-drive. With your i7 and 12 threads it should be crazy fast.

[guy lateur]

Ok, I just compiled again on my SSD (OCZ Agility3) and it took about 1 hour and 5 minutes, which is about 15% faster. This is a significant gain, but still not crazy fast. I also set threads=12, btw.

Any other things that I could test to see why this is way slower than expected? Maybe I have a bad internet connection, so maybe I could seperate the downloading of the files from the actual build process? During most of the process, 6 threads are running at about 10% usage, which is better then before but could possibly be even a lot better, I guess. Although I should add that during the occasional 'burst' mode, I actually got 100% usage on all my threads.

Originally Posted by bebbo

11!1!1elf!1!!!!

Do you mean try using Linux? Because this has been suggested before. If so, what distribution would you suggest, aimed at programming/comiling work? I'll be ordering a new SSD soon (Samsung 850 Pro) (any other suggestions for this?), so I might as well give it a go.

Also, I get an error while installing the additional SDK's, which I'm pretty sure wasn't there before:

DEBUG: execute "sfdc --quiet --target=m68k-amigaos --mode=proto --output=/opt/m68k-amigaos/m68k-amigaos/include/proto/ahi.h m68k-amigaos-ahi/Developer/Include/SFD/ahi_li                             b.sfd"
Traceback (most recent call last):
  File "./toolchain-m68k", line 880, in <module>
    globals()[action].__call__(*args.args)
  File "./toolchain-m68k", line 776, in install_sdk
    process_sdk(pkg, name, files)
  File "/home/guy/amigaos-cross-toolchain/common.py", line 38, in wrapper
    return fn(*args, **kwargs)
  File "/home/guy/amigaos-cross-toolchain/common.py", line 359, in wrapper
    fn(*args, **kwargs)
  File "./toolchain-m68k", line 692, in process_sdk
    '--output=' + proto, source)
  File "/home/guy/amigaos-cross-toolchain/common.py", line 38, in wrapper
    return fn(*args, **kwargs)
  File "/home/guy/amigaos-cross-toolchain/common.py", line 217, in execute
    subprocess.check_call(cmd)
  File "/usr/lib/python2.7/subprocess.py", line 181, in check_call
    retcode = call(*popenargs, **kwargs)
  File "/usr/lib/python2.7/subprocess.py", line 168, in call
    return Popen(*popenargs, **kwargs).wait()
  File "/usr/lib/python2.7/subprocess.py", line 390, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1024, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

[bebbo]

well, I am also using cygwin 32bit and clean then build is taking 18 mins on my 5 year old laptop - with ssd.

note: usually you don't need to clean after a pull. Just build.

And 'test' is running until hello-iostream

[guy lateur]

Originally Posted by bebbo

well, I am also using cygwin 32bit and clean then build is taking 18 mins on my 5 year old laptop - with ssd.

note: usually you don't need to clean after a pull. Just build.

And 'test' is running until hello-iostream

Wow, that's more than 3 times faster! I have no idea what could be causing this..

Btw, I always start from a fresh pull while doing these tests; I don't do a clean.

[bebbo]

Originally Posted by guy lateur

Btw, I always start from a fresh pull while doing these tests; I don't do a clean.

why?

[guy lateur]

Originally Posted by bebbo

why?

Because that's what I did the first time, I guess, and I'd like my results to be comparable. But I hear ya; I just did a clean and I'm rebuilding now..

[guy lateur]

Originally Posted by bebbo

And 'test' is running until hello-iostream

Same here. Do you get the error while installing the additional SDK's?

[bebbo]

Originally Posted by guy lateur

Same here. Do you get the error while installing the additional SDK's?

uhm - never tested

[guy lateur]

I'm using this command, btw:

./toolchain-m68k --prefix=/opt/m68k-amigaos --threads=12 build

Could that prefix thing have anything to do with anything?