GCC 6.2 toolchain for AmigaOS 3

[pipper]

I just checked. It works :-)

At first it crashed with newlib, but it ultimately turned out just to be a matter of not enough stacksize. Noixemul is still recommended as it produces a much smaller executable.

WRT vbcc: I don't know why vbcc is part of the toolchain at all (vasm is very useful to have in there, though!). In general, Bebbo is more concerned about making gcc great.

[bebbo]

Originally Posted by midwan

Thanks, I'll look into that and see.

Meanwhile, I found it strange that using the toolchains bundled "vbcc" it fails to compile (received an "Ouf of memory" error!), while it compiles normally with a standalone separate VBCC installation (e.g. following my guide here: https://blitterstudio.com/setting-up...ross-compiler/). Perhaps it has to do with the target configs? I didn't spend too much time to troubleshoot this.

@bebbo: could we get the target configs in the toolchain also, or otherwise "fix" the VBCC installation? It would be great if we could have one up-to-date toolchain that people can use, including both compilers.

Please provide a pull request for the fix.

[thyslo]

Yesterday I used this toolchain to compile a bigger application I originally created with StormC4 / gcc 2.95 mode.

As expected the binary is bigger, but the program also runs faster, only taking about 80% of the time for its operation.

But one issue I noticed is that it crashed as soon as I changed the CPU to 68000 (WinUAE). On 68020-68040 it ran without problems. Binaries are attached.

Btw I don't open the libraries manually. As the StormC startup code allows to auto-open the libraries I used that feature. Could this be a problem with the toolchain?

[bebbo]

Originally Posted by thyslo

Yesterday I used this toolchain to compile a bigger application I originally created with StormC4 / gcc 2.95 mode.

As expected the binary is bigger, but the program also runs faster, only taking about 80% of the time for its operation.

But one issue I noticed is that it crashed as soon as I changed the CPU to 68000 (WinUAE). On 68020-68040 it ran without problems. Binaries are attached.

Btw I don't open the libraries manually. As the StormC startup code allows to auto-open the libraries I used that feature. Could this be a problem with the toolchain?

two improvements:

• don't initialize static variables with constuctors inside of if.
  Why? It triggers a bunch of code to ensure that this variable is only initialized once.
• provide an own 'operator new' (until I found an improvement), since the standard provides one which uses exceptions... tada ... -fno-exceptions does not really help.

static const SimpleString __s = "";
const SimpleString& DiffFilePartition::GetDiffLineText(size_t p_Index) const
{
  if(m_DiffLinesArray.IsEmpty()|| p_Index >= m_DiffLinesArray.Size())
  {
    return __s;
  }

and

void * operator new (std::size_t sz)
{
  void *p = malloc(sz);
  if (p)
    return p;
  perror("std::bad_alloc");
  abort();
}

both helps with code size plus it runs on 68000 too.

[thyslo]

Wow, smaller and faster, great

Thanks for these hints!

[thyslo]

Hi bebbo,

unfortunately I wasn't able to recreate the good binary result you posted here.

Using this flags

CXXFLAGS=-Wall -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -noixemul -Os

And doing the operator new() overloading globally in main.cpp.

Did you use some other magic there?

[bebbo]

Originally Posted by thyslo

Hi bebbo,

unfortunately I wasn't able to recreate the good binary result you posted here.

Using this flags

CXXFLAGS=-Wall -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -noixemul -Os

And doing the operator new() overloading globally in main.cpp.

Did you use some other magic there?

yes magic: build all libraries with -Os. Do a

export CFLAGS_FOR_TARGET="-Os -fomit-frame-pointer"

before `make all`. Needs a `make clean-libnix` to get libnix build with that option. And so on.

[bebbo]

Originally Posted by bebbo

• provide an own 'operator new' (until I found an improvement), since the standard provides one which uses exceptions... tada ... -fno-exceptions does not really help.

void * operator new (std::size_t sz)
{
  void *p = malloc(sz);
  if (p)
    return p;
  perror("std::bad_alloc");
  abort();
}

From now on

gcc version 6.5.0b 190302093159 (GCC)

simply specify `-fno-exceptions` when linking and that simple new operator is used.

[Leffmann]

Has anyone been able to build vasm, vlink, and vbcc? I can get the gcc toolchain to build with no errors on macOS, but when I use it to build vasm I get errors like these:

amiga-gcc/m68k-amigaos/sys-include/stdio.h:66:9: error: unknown type name '__FILE'
 typedef __FILE FILE;

amiga-gcc/m68k-amigaos/sys-include/stdio.h:747:26: error: dereferencing pointer to incomplete type 'struct _reent'
  return (__sgetc_r(_ptr, _stdin_r(_ptr)));

amiga-gcc/lib/gcc/m68k-amigaos/6.5.0b/../../../../m68k-amigaos/bin/ld: cannot find ncrt0.o: No such file or directory

[bebbo]

Originally Posted by Leffmann

Has anyone been able to build vasm, vlink, and vbcc? I can get the gcc toolchain to build with no errors on macOS, but when I use it to build vasm I get errors like these:

amiga-gcc/m68k-amigaos/sys-include/stdio.h:66:9: error: unknown type name '__FILE'
 typedef __FILE FILE;

amiga-gcc/m68k-amigaos/sys-include/stdio.h:747:26: error: dereferencing pointer to incomplete type 'struct _reent'
  return (__sgetc_r(_ptr, _stdin_r(_ptr)));

amiga-gcc/lib/gcc/m68k-amigaos/6.5.0b/../../../../m68k-amigaos/bin/ld: cannot find ncrt0.o: No such file or directory

I suggest using -noixemul.

Plus you have to fix tfloat.h that strtod is used instead of strtold.

the attached Makefile.68k can be used directly with make -f Makefile.68k

[Amiga68k]

bebbo, I followed your guide at this url. I didn't build the toolchain myself, but used your installer.

After creating the helloworld project, I received the error messages that g++ and gcc are not in the PATH...

I did two things:
- Added the location where the bin folder is to the PATH environment variable in Windows system settings
- Renamed m68k-amigaos-g++.exe and m68k-amigaos-gcc.exe to respectively g++.exe and gcc.exe

The above steps make the error messages go away, but this can't be the idea behind it, can it?

Where you are stating /opt/amiga/bin in the guide, I assume you mean the 'amiga-gcc/bin' directory that your toolchain creates, right?

*EDIT: next error when rebuilding the project after change of settings as mentioned in the guide:

Program "make" not found in PATH

Went to the directory where your toolchain is installed and there is a file called _make.exe...

Am I missing an important additional step that is not mentioned in the guide? Should I have an installed cygwin environment that might add all these things to the PATH?

*EDIT2: the problems with make are gone after running the cmdline.bat file

[Leffmann]

Originally Posted by bebbo

I suggest using -noixemul.

Plus you have to fix tfloat.h that strtod is used instead of strtold.

the attached Makefile.68k can be used directly with make -f Makefile.68k

Thanks, I've already tried -noixemul and the various -mcrt options, but I can't get it to work. I think the macOS build procedure somehow quietly fails, but I have no more useful info.

[bebbo]

[QUOTE=Amiga68k;1312071]bebbo, I followed your guide at this url. I didn't build the toolchain myself, but used your installer.

After creating the helloworld project, I received the error messages that g++ and gcc are not in the PATH...

I did two things:
- Added the location where the bin folder is to the PATH environment variable in Windows system settings
- Renamed m68k-amigaos-g++.exe and m68k-amigaos-gcc.exe to respectively g++.exe and gcc.exe
[/code]

I guess you skipped the step to enter the Cross Compiler Prefix and the Cross Compiler Path
* prefix is "m68k-amigaos-" and
* the path to the bin folder (e.g. "/opt/amiga/bin") depends on your installation

please undo the rename.

Originally Posted by Amiga68k

The above steps make the error messages go away, but this can't be the idea behind it, can it?

Where you are stating /opt/amiga/bin in the guide, I assume you mean the 'amiga-gcc/bin' directory that your toolchain creates, right?

*EDIT: next error when rebuilding the project after change of settings as mentioned in the guide:

Program "make" not found in PATH

Went to the directory where your toolchain is installed and there is a file called _make.exe...

Am I missing an important additional step that is not mentioned in the guide? Should I have an installed cygwin environment that might add all these things to the PATH?

*EDIT2: the problems with make are gone after running the cmdline.bat file

ah, yes - running the cmdline.bat is mandatory for now... since that script creates the make.exe wrapper for windows.

[bebbo]

Originally Posted by Leffmann

Thanks, I've already tried -noixemul and the various -mcrt options, but I can't get it to work. I think the macOS build procedure somehow quietly fails, but I have no more useful info.

If I have access to an OSX system, I'll test it, but there's none around.
Maybe someone else can help here?

[Amiga68k]

Originally Posted by bebbo

I guess you skipped the step to enter the Cross Compiler Prefix and the Cross Compiler Path
* prefix is "m68k-amigaos-" and
* the path to the bin folder (e.g. "/opt/amiga/bin") depends on your installation

please undo the rename.

Nope, made sure I followed your guide to the letter... Just tested with and without quotes, but it's still complaining that "g++" and "gcc" are not in PATH when entering the values during the creation of the new project for the first time.

However, when I go to C/C++ Build Settings and do an additional "Apply and Close", the error messages are no longer there...

(perhaps a bug in Eclipse?)

[Leffmann]

Originally Posted by Leffmann

Thanks, I've already tried -noixemul and the various -mcrt options, but I can't get it to work. I think the macOS build procedure somehow quietly fails, but I have no more useful info.

Originally Posted by bebbo

If I have access to an OSX system, I'll test it, but there's none around.
Maybe someone else can help here?

It's very picky about the build environment. I removed the manually installed dependencies and added them via Homebrew, and installed GCC instead of the older version of clang and its GCC wrapper, and it works better now. There are still unexpected linker errors about missing library bases, but I can just add those manually.

[bebbo]

Originally Posted by Leffmann

It's very picky about the build environment. I removed the manually installed dependencies and added them via Homebrew, and installed GCC instead of the older version of clang and its GCC wrapper, and it works better now. There are still unexpected linker errors about missing library bases, but I can just add those manually.

It s*cks as usual, but builds it...
... I updated https://franke.ms/download/amiga-gcc-macos.tgz

and vasm builds with the Makefile and changes from above.

PS: maybe you should try an absolute path as prefix...

[arti]

I can't compile libnix.
*** No rules to make 'nrcrt0.S', needed by 'nrcrt0.o'. Stop.

Any ideas?

[bebbo]

Originally Posted by arti

I can't compile libnix.
*** No rules to make 'nrcrt0.S', needed by 'nrcrt0.o'. Stop.

Any ideas?

invoke configure with an absolut path plus use a separate build folder.

[meeku]

Hi, I've followed the guide to get eclipse/bgdbserver up and running.. It all worked up until trying to actually debug where I get an error from bgdbserver (on winUAE and echoed to Eclipse) saying:
failed to load program /test/hello-world;exit

Any ideas?