GCC 6.2 toolchain for AmigaOS 3

[bebbo]

Originally Posted by alkis

So, I have a small project (like the command "ls" in linux) and uses nostartup and thus it has a custom startup in assembly.

The exe size is at ~19k, and if I add -fbaserel -msmall-code goes at ~15k. Impressive and all but....what is the inner workings for a4?

I probably have to provide a "geta4()" in my startup, right? (and also call it at start, to set it once)
But to what value should I set it to? Does linker expose a symbol for that purpose when -fbaserel is used?

there is a symbol:

_geta4:     lea    ___a4_init,a4
        rts

You'll only have to provide that function if there are functions using __saveds, but you still have to load a4 once.

Also the option -fno-toplevel-reorder may come handy to keep the code order.

[pipper]

This is a cross development platform, i.e. you code and compile on PC and transfer the executable to the Amiga.

The way I do it is as follows: my native host system is a Windows box. On it I run a Ubuntu Linux VM. On that Linux I downloaded and compiled the toolchain. I do Amiga code development on there as well.
On the windows Machine I also run WinUAE. This is my tested system. Both, the Linux VM and WinUAE map a Windows directory to be visible in the guest system. This way I can share the executable to the emulated Amiga by just doing a simple file copy from within Linux.

[nogginthenog]

Originally Posted by Akira

It's just that my only Linux machines are Raspberry Pis. I don't want to run Linux on my Windows PC, although I usually have a virtual machine ready for special cases.

Use a VM. I have a 1Gb RAM Debian VM under Hyper-V (included in Win 10 Pro) which compiles Bebo's GCC 6 fine.

I did try to compile on a PI and with a bit of hacking it did work (not well tested) but I would not recommend it. It took hours and ran out of memory a few times

Compiling GCC needs a lot of resources. I'd also recommend an I7 with SSD.
If you run Win10 I think somebody got it working in Win10 Bash.

[Leffmann]

Originally Posted by nogginthenog

Compiling GCC needs a lot of resources. I'd also recommend an I7 with SSD.
If you run Win10 I think somebody got it working in Win10 Bash.

Mount a RAM-drive and clone and build in there, it will speed things up a lot. And turn Windows Defender real-time protection off temporarily, or it will scan every single file produced during the build.

[Amiga1992]

Originally Posted by nogginthenog

Use a VM. I have a 1Gb RAM Debian VM under Hyper-V (included in Win 10 Pro) which compiles Bebo's GCC 6 fine.

I did try to compile on a PI and with a bit of hacking it did work (not well tested) but I would not recommend it. It took hours and ran out of memory a few times

Compiling GCC needs a lot of resources. I'd also recommend an I7 with SSD.
If you run Win10 I think somebody got it working in Win10 Bash.

Yeah no way I'd try it on a Raspberry, I compiled code on it once, NEVER AGAIN

I have WIndows 7 so VM it is

[pipper]

One workflow I’d like to use would be the Linux Subsystem on Windows. I.e. do the cross compilation in the Ubuntu-on-Windows shell.
(Eventually, a native windows gcc would be the icing on the cake)

But to my knowledge the current gcc toolchain does not produce a 64Bit gcc Compiler, so that’s not going to fly as of now

[alpine9000]

Originally Posted by pipper

One workflow I’d like to use would be the Linux Subsystem on Windows. I.e. do the cross compilation in the Ubuntu-on-Windows shell.
(Eventually, a native windows gcc would be the icing on the cake)

But to my knowledge the current gcc toolchain does not produce a 64Bit gcc Compiler, so that’s not going to fly as of now

Why wouldn't it work on the Linux Subsystem on Windows ?

It runs fine on cygwin.

[pipper]

AFAIK it doesn’t run 32bit executables. The gcc that the toolchain currently produces is 32bit.

[alpine9000]

Originally Posted by pipper

AFAIK it doesn’t run 32bit executables. The gcc that the toolchain currently produces is 32bit.

Ah that is a pain. I think it's probably only binutils that would care about being 32bit. I run a 64bit gcc on OSX, but I don't use bintutils.

[bebbo]

Originally Posted by pipper

AFAIK it doesn’t run 32bit executables. The gcc that the toolchain currently produces is 32bit.

It's quite simple what my amiga-gcc toolchain creates:

On a 32bit OS amiga-gcc creates 32bit gcc and 32bit binutils.
On a 64bit OS amiga-gcc creates 64bit gcc and 64bit binutils.
On Linux ... Linux gcc and Linux binutils
... Windows ... Windows ... Windows.

[pipper]

I just gave it a shot and tried compiling the toolchain in WSL... no cigar:

make all -j8 PREFIX=/home/matze/amiga-gcc-out

Making all in po
make[4]: Entering directory `/home/matze/amiga-gcc/build/binutils/bfd/po'
( if test 'x/home/matze/amiga-gcc/projects/binutils/bfd/po' != 'x.'; then \
            posrcprefix='/home/matze/amiga-gcc/projects/binutils/bfd/'; \
          else \
            posrcprefix="../"; \
          fi; \
          rm -f SRC-POTFILES-t SRC-POTFILES \
            && (sed -e '/^#/d' \
                    -e '/^[     ]*$/d' \
                    -e "s@.*@   $posrcprefix& \\\\@" < /home/matze/amiga-gcc/projects/binutils/bfd/po/SRC-POTFILES.in \
                | sed -e '$s/\\$//') > SRC-POTFILES-t \
            && chmod a-w SRC-POTFILES-t \
            && mv SRC-POTFILES-t SRC-POTFILES )
( rm -f BLD-POTFILES-t BLD-POTFILES \
            && (sed -e '/^#/d' \
                    -e '/^[     ]*$/d' \
                    -e "s@.*@   ../& \\\\@" < /home/matze/amiga-gcc/projects/binutils/bfd/po/BLD-POTFILES.in \
                | sed -e '$s/\\$//') > BLD-POTFILES-t \
            && chmod a-w BLD-POTFILES-t \
            && mv BLD-POTFILES-t BLD-POTFILES )
cd .. \
          && CONFIG_FILES=po/Makefile.in:po/Make-in \
             CONFIG_HEADERS= /bin/sh ./config.status
config.status: creating po/Makefile.in
config.status: executing depfiles commands
config.status: executing default commands
make[4]: Leaving directory `/home/matze/amiga-gcc/build/binutils/bfd/po'
make[4]: Entering directory `/home/matze/amiga-gcc/build/binutils/bfd/po'
file=/home/matze/amiga-gcc/projects/binutils/bfd/po/`echo fr | sed 's,.*/,,'`.gmo \
          && rm -f $file && PATH=../src:$PATH no -o $file /home/matze/amiga-gcc/projects/binutils/bfd/po/fr.po
/bin/sh: 2: no: not found
make[4]: *** [fr.gmo] Error 127
make[4]: Leaving directory `/home/matze/amiga-gcc/build/binutils/bfd/po'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/matze/amiga-gcc/build/binutils/bfd'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/matze/amiga-gcc/build/binutils/bfd'
make[1]: *** [all-bfd] Error 2
make[1]: Leaving directory `/home/matze/amiga-gcc/build/binutils'
make: *** [build/binutils/_done] Error 2

[Marlon_]

Originally Posted by pipper

I just gave it a shot and tried compiling the toolchain in WSL... no cigar:

make all -j8 PREFIX=/home/matze/amiga-gcc-out

Are you sure you have everything required installed? The WSL should be no different than running on an actual GNU/Linux setup.

[bebbo]

Originally Posted by Marlon_

Are you sure you have everything required installed? The WSL should be no different than running on an actual GNU/Linux setup.

I agree.

Plus while finding errors you should omit the -j8 to get consistent log output

[Toni Wilen]

WSL build worked for me except libdebug (but I use Windows 10 insider version which includes multiple WSL updates. Which may make a difference.):

mkdir -p build/libdebug
cd build/libdebug && CFLAGS="-Os -g -fomit-frame-pointer" /home/twilen/amiga-gcc/projects/libdebug/configure --prefix=/opt/amiga --target=m68k-amigaos --host=m68k-amigaos
checking build system type... x86_64-unknown-linux-gnu
checking host system type... m68k-unknown-amigaos
checking target system type... m68k-unknown-amigaos
checking whether make sets $(MAKE)... yes
checking for SFDC... SFDC
checking for m68k-amigaos-gcc... m68k-amigaos-gcc
checking for m68k-amigaos-ar... m68k-amigaos-ar
checking for m68k-amigaos-ranlib... m68k-amigaos-ranlib
checking for m68k-amigaos-gcc... (cached) m68k-amigaos-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether m68k-amigaos-gcc accepts -g... yes
checking for m68k-amigaos-gcc option to accept ISO C89... none needed
checking for m68k-amigaos-ranlib... (cached) m68k-amigaos-ranlib
checking for a BSD-compatible install... /usr/bin/install -c
/home/twilen/amiga-gcc/projects/libdebug/configure: line 3243: AC_ARFLAGS: command not found
checking for an ANSI C-conforming const... yes
checking for inline... inline
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config.h
config.status: executing exec_dbg_inline.h commands
Processing SFD file 'exec_dbg_lib.sfd'.
Writing to 'exec_dbg_inline.h'
All done.
cd build/libdebug && make
make[1]: Entering directory '/home/twilen/amiga-gcc/build/libdebug'
m68k-amigaos-gcc -W -Wall -Wstrict-prototypes -Os -g -fomit-frame-pointer -DUSE_SERIAL -c /home/twilen/amiga-gcc/projects/libdebug/debug.c -o kdebug.o
/home/twilen/amiga-gcc/projects/libdebug/debug.c: In function 'KDoFmt':
/home/twilen/amiga-gcc/projects/libdebug/debug.c:117:3: warning: function declaration isn't a prototype [-Wstrict-prototypes]
   RawDoFmt(formatString, dataStream,
   ^~~~~~~~
m68k-amigaos-ar @ARFLAGS@ libdebug.a kdebug.o
m68k-amigaos-ar: illegal option -- @
Usage: m68k-amigaos-ar [emulation options] [-]{dmpqrstx}[abcfilNoPsSuvV] [member-name] [count] archive-file file...
       m68k-amigaos-ar -M [<mri-script]
 commands:
  d            - delete file(s) from the archive
  m[ab]        - move file(s) in the archive
  p            - print file(s) found in the archive
  q[f]         - quick append file(s) to the archive
  r[ab][f][u]  - replace existing or insert new file(s) into the archive
  t            - display contents of archive
  x[o]         - extract file(s) from the archive
 command specific modifiers:
  [a]          - put file(s) after [member-name]
  [b]          - put file(s) before [member-name] (same as [i])
  [N]          - use instance [count] of name
  [f]          - truncate inserted file names
  [P]          - use full path names when matching
  [o]          - preserve original dates
  [u]          - only replace files that are newer than current archive contents
 generic modifiers:
  [c]          - do not warn if the library had to be created
  [s]          - create an archive index (cf. ranlib)
  [S]          - do not build a symbol table
  [v]          - be verbose
  [V]          - display the version number
 emulation options:
  No emulation specific options
m68k-amigaos-ar: supported targets: amiga a.out-amiga srec symbolsrec tekhex binary ihex
Makefile:53: recipe for target 'libdebug.a' failed
make[1]: *** [libdebug.a] Error 1
make[1]: Leaving directory '/home/twilen/amiga-gcc/build/libdebug'
Makefile:601: recipe for target 'build/libdebug/_done' failed
make: *** [build/libdebug/_done] Error 2

pfs3aio compilation works fine with WSL build amiga-gcc.

Also is ixemul supposed to work? (Not that I need it)

make ixemul -> "make: Nothing to be done for 'ixemul'"

Previously I used cygwin but it got annoying because tool chain building takes forever in cygwin environment compared to WSL.

EDIT: when I tried previously (1-2 weeks ago), I got errors if I used prefix, I think there was some path that pointed to /opt/amiga even when prefix was set.

[bebbo]

Originally Posted by Toni Wilen

WSL build worked for me except libdebug (but I use Windows 10 insider version which includes multiple WSL updates. Which may make a difference.):

...

pfs3aio compilation works fine with WSL build amiga-gcc.

Also is ixemul supposed to work? (Not that I need it)

make ixemul -> "make: Nothing to be done for 'ixemul'"

Previously I used cygwin but it got annoying because tool chain building takes forever in cygwin environment compared to WSL.

EDIT: when I tried previously (1-2 weeks ago), I got errors if I used prefix, I think there was some path that pointed to /opt/amiga even when prefix was set.

1. If this happens, go to projects/libdebug and run "git checkout configure".
2. ixemul is not yet done and thus not provided.
3. if a wrong prefix is still used then you forgot to clean.

[pipper]

The log I gave was produced by omitting -j8.
Not sure what to make of the error “no not found”.
I don’t know of any tool called ‘no’

[bebbo]

Originally Posted by pipper

The log I gave was produced by omitting -j8.
Not sure what to make of the error “no not found”.
I don’t know of any tool called ‘no’

Maybe you are missing /usr/bin/msgfmt which is provided by gettext ?

[Toni Wilen]

Originally Posted by bebbo

1. If this happens, go to projects/libdebug and run "git checkout configure".

This fixed it.

[Leffmann]

Originally Posted by pipper

I just gave it a shot and tried compiling the toolchain in WSL... no cigar

This is how I got it to build using a fresh WSL Debian:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install  build-essential  autoconf  git  lhasa  libgmp-dev  libmpfr-dev  libmpc-dev  flex  gettext
git clone ...
cd amiga-gcc
make update all

You may have to run

make all

several times, but eventually it does finish.

@bebbo

Small bug-report: whenever I enable

-fbaserel

it reloads the library base for each call, even when they are in succession and to the same library.

[bebbo]

Originally Posted by Leffmann

This is how I got it to build using a fresh WSL Debian:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install  build-essential  autoconf  git  lhasa  libgmp-dev  libmpfr-dev  libmpc-dev  flex  gettext
git clone ...
cd amiga-gcc
make update all

You may have to run

make all

several times, but eventually it does finish.

@bebbo

Small bug-report: whenever I enable

-fbaserel

it reloads the library base for each call, even when they are in succession and to the same library.

1. you have to run it separately

make update
make all

2. it's not a bug, it's rather a feature that in some cases reloading of a6 is optimized away. Compare this to other compilers.