GCC 6.2 toolchain for AmigaOS 3

[alancfrancis]

Aha uae_fpu_model=68882 is my friend.

[bebbo]

Originally Posted by alancfrancis

Hah! Very good on both alerts. :-) I cant see a way in FS-UAE to "add" an FPU. My real A1200 has a 68882 on the P5 board. I'll try that when I get a minute.

https://fs-uae.net/docs/options

uae_fpu_model = 68882

[mdx54]

Hello, I'm running into a problem with the linker failing to resolve typical *nix symbols.

Any clues what's going on here?

/home/project/opt/amiga//bin/m68k-amigaos-gcc -Lmodplug/usr  -lc -lm -lg -L/home/project/opt/amiga//m68k-amigaos/lib -o project  main.o sdl2.o -lSDL -lpthread -lmodplug  
/home/project/opt/amiga/lib64/gcc/m68k-amigaos/6.5.0b/../../../../m68k-amigaos/bin/ld:   /home/project/opt/amiga//m68k-amigaos/lib/libSDL.a(SDL_yuv_sw.go-00000008.o):  in functio
n `memmove': 
SDL_yuv_sw.go-00000008.o:(.text+0x0): multiple definition of  `memmove';  /home/project/opt/amiga//m68k-amigaos/lib/libc.a(lib_a-memmove.o):lib_a-memmove.o:(.text+0x0):  first de
fined here 
/home/project/opt/amiga/lib64/gcc/m68k-amigaos/6.5.0b/../../../../m68k-amigaos/bin/ld:   /home/project/opt/amiga//m68k-amigaos/lib/libSDL.a(SDL_yuv_sw.go-00000008.o):  in functio
n `memchr': 
SDL_yuv_sw.go-00000008.o:(.text+0x50): multiple definition of  `memchr';  /home/project/opt/amiga//m68k-amigaos/lib/libc.a(lib_a-memchr.o):lib_a-memchr.o:(.text+0x0):  first defi
ned here 
/home/project/opt/amiga/lib64/gcc/m68k-amigaos/6.5.0b/../../../../m68k-amigaos/bin/ld:   /home/project/opt/amiga//m68k-amigaos/lib/libSDL.a(SDL_yuv_sw.go-00000008.o):  in functio
n `strlen': 
SDL_yuv_sw.go-00000008.o:(.text+0x82): multiple definition of  `strlen';  /home/project/opt/amiga//m68k-amigaos/lib/libc.a(lib_a-strlen.o):lib_a-strlen.o:(.text+0x0):  first defi
ned here 
/home/project/opt/amiga/lib64/gcc/m68k-amigaos/6.5.0b/../../../../m68k-amigaos/bin/ld: main.o: in function `main': 
main.o:(.text+0x35e): undefined reference to `stat' 
/home/project/opt/amiga/lib64/gcc/m68k-amigaos/6.5.0b/../../../../m68k-amigaos/bin/ld:  main.o:(.text+0x556): undefined reference to `__sF' 
/home/project/opt/amiga/lib64/gcc/m68k-amigaos/6.5.0b/../../../../m68k-amigaos/bin/ld:  main.o:(.text+0x5b0): undefined reference to `__sF' 
/home/project/opt/amiga/lib64/gcc/m68k-amigaos/6.5.0b/../../../../m68k-amigaos/bin/ld:  main.o:(.text+0x5d8): undefined reference to `__sF' 
/home/project/opt/amiga/lib64/gcc/m68k-amigaos/6.5.0b/../../../../m68k-amigaos/bin/ld: sdl2.o: in function `SDL_AllocPalette': 
sdl2.o:(.text+0x728): undefined reference to `__sF' 
/home/project/opt/amiga/lib64/gcc/m68k-amigaos/6.5.0b/../../../../m68k-amigaos/bin/ld:  sdl2.o:(.text+0x74c): undefined reference to `__sF' 
/home/project/opt/amiga/lib64/gcc/m68k-amigaos/6.5.0b/../../../../m68k-amigaos/bin/ld:  sdl2.o:sdl2.o:(.text+0x8a): more undefined references to `__sF' follow 
/home/project/opt/amiga/lib64/gcc/m68k-amigaos/6.5.0b/../../../../m68k-amigaos/bin/ld:   /home/project/opt/amiga//m68k-amigaos/lib/libSDL.a(SDL_quit.go-00000043.o):(.text+0x10):
 undefined reference to `signal' 
/home/project/opt/amiga/lib64/gcc/m68k-amigaos/6.5.0b/../../../../m68k-amigaos/bin/ld:   /home/project/opt/amiga//m68k-amigaos/lib/libSDL.a(SDL_quit.go-00000043.o):  in function 
`SDL_QuitInit': 
SDL_quit.go-00000043.o:(.text+0x64): undefined reference to `signal' 
/home/project/opt/amiga/lib64/gcc/m68k-amigaos/6.5.0b/../../../../m68k-amigaos/bin/ld:   /home/project/opt/amiga//m68k-amigaos/lib/libSDL.a(SDL_quit.go-00000043.o):  in function 
`SDL_QuitQuit': 
SDL_quit.go-00000043.o:(.text+0xa4): undefined reference to `signal' 
/home/project/opt/amiga/lib64/gcc/m68k-amigaos/6.5.0b/../../../../m68k-amigaos/bin/ld:   /home/project/opt/amiga//m68k-amigaos/lib/libc.a(lib_a-gettimeofdayr.o):  in function `_g
ettimeofday_r': 
lib_a-gettimeofdayr.o:(.text+0x14): undefined reference to `_gettimeofday' 
collect2: error: ld returned 1 exit status 
make: *** [Makefile:45: project] Error 1

[alkis]

try passing -noixemul to the compiler

[mdx54]

Thank you, I had -noixemul passed in CFLAGS internally in Makefile, but noticed the flag is missing from linker output. Adding it manually to LDFLAGS fixes everything except:

/home/project/opt/amiga//bin/m68k-amigaos-gcc -Wall -Wpedantic -MMD -I/home/project/opt/amiga//m68k-amigaos/include/SDL  -I. -I./modplug/dev -I/home/project/opt/amiga//m68k-amigaos/include -g   -c -o main.o main.c
/home/project/opt/amiga//bin/m68k-amigaos-gcc -Wall -Wpedantic -MMD -I/home/project/opt/amiga//m68k-amigaos/include/SDL  -I. -I./modplug/dev -I/home/project/opt/amiga//m68k-amigaos/include -g   -c -o sdl2.o sdl2.c
/home/project/opt/amiga//bin/m68k-amigaos-gcc -noixemul -Lmodplug/usr -L/home/project/opt/amiga//m68k-amigaos/lib -o project main.o sdl2.o -lSDL -lpthread -lmodplug
/home/project/opt/amiga/lib64/gcc/m68k-amigaos/6.5.0b/../../../../m68k-amigaos/bin/ld: main.o: in function `':
/home/project/g/project/main.c:94: undefined reference to `getopt_long'
collect2: error: ld returned 1 exit status
make: *** [Makefile:42: project] Error 1

That is odd, seeing as the symbol is listed as an internal function in several of the complied libs, including libc.a:

/home/project/opt/amiga/bin/m68k-amigaos-nm /home/project/opt/amiga/m68k-amigaos/lib/libc.a | grep getopt_long$
00000cd6 T _getopt_long

Tried passing "-L/home/project/opt/amiga/m68k-amigaos/lib -lc" to LDFLAGS & CFLAGS, no joy.

[Samurai_Crow]

Check the linking order. Order is significant.

[bebbo]

getopt_long is not yet present in libnix.
=> add it as a separate .o file
=> contribute with a pull request

... I added getopt_long

[mdx54]

Originally Posted by bebbo

getopt_long is not yet present in libnix.
=> add it as a separate .o file
=> contribute with a pull request

... I added getopt_long

Appreciate it bebbo, your advice helped, I was going to contribute a simple fix that involved two files between the cloned ixemul & libnix repos:

cp ixemul/utils/getopt.c libnix/sources/nix/stdlib/
cp ixemul/utils/getopt.h libnix/sources/headers/

Yours involves only nix/misc/getopt.c, which is obviously shorter.



By the way, the order in which the targets compile appears to be relevant; with multiple jobs I get an occasional failure, should a dependency for a target fail to compile ahead of the target. I got one for libdebug recently, while doing a 'make -j4 all' on a fairly slow host. Re-running it fixes the problem.


May I ask, is AGA supported in any capacity in libSDL12? My code does compile now but I get failure to open a video device. I'm trying to figure out how to link my code against the static SDL_AGA library from aminet, which won't link, is there any way to link or convert the 'ar archive random library' type to a proper 'AmigaOS object/library data'?

file libSDL.a 
libSDL.a: AmigaOS object/library data 
file SDL_AGA_060_DEBUG.a 
SDL_AGA_060.a: current ar archive random library

[Samurai_Crow]

The old binutils used to have a utility to convert ELF objects and archives to Amiga formatted objects and linker libs. It might be out of date though.

[Olaf Barthel]

Originally Posted by bebbo

Well, to be fair: any number is a reasonable stack size. So this sounds reasonable.

Some stack size choices are riskier than others.

Couple of years back I wrote clib2 so that I could more easily port Samba 2.0.4 to the Amiga (it's been awhile and I managed to reach that goal). Part of the journey to getting Samba 2.0.4 ported was to verify that clib2 actually did work properly and didn't have any bugs which would doom the project. So I thought that just maybe I could use it to build the GNU binutils and GCC 2.95.3 with it, as a test. If the clib2 implementation had subtle & nasty bugs, then these tools maybe could help to surface them.

And it worked out, eventually. I started with the ixemul.library build of GCC 2.95.3 and then completely bootstrapped it to use clib2 instead, in several intermediate steps.

Stack size usage was a major issue during that exercise. The GCC 2.95.3 implementation was particularly fond of using the built-in alloca() function which "allocates" local storage from the stack. This led to stack size requirements in the range of 100,000 bytes for the compiler toolchain. I specifically built stack size usage monitoring into the clib2 runtime environment to gauge the effect. And my own clib2-based GCC 2.95.3 verifies that it has at least 100,000 bytes of stack to work with, allocating a sufficiently large stack if necessary.

Reducing the stack size usage of GCC and the binutils involved replacing the alloca() function with one which did allocate memory instead of consuming stack space. That happened at the expense of performance, because memory allocation is expensive on the Amiga, but then it worked out well in the end.

While I have no idea how much stack space the current libnix-based GCC build requires, I would advise caution if GCC still uses alloca() as much as it did for the 2.95.3 release. 32 KBytes of stack space might be far too low.

Sadly, the clib2-based GCC 2.95.3 did not ferret out one of the subtle & nasty bugs I was concerned about. My strcspn() implementation was broken, which affected Samba 2.0.4 in a big way, since it both uses strcspn() and strtok() to process its many configuration files To find that issue you have to get lucky, and I did, eventually.

[kas1e]

@All
Is there anything which can bring an warning about "A process called a DOS function with a non longword-aligned Anchor. Function: "MatchFirst()" " even if in the code i didn't have MatchFirst calls at all.

Can it be that link libraries use it inderectly somehow ? Or some other DOS/etc functions may use it under the hood ?

[alkis]

Only clib2 seems to reference MatchFirst.

What is your compile/link flags?

grep -iR --include='*.c' MatchFirst 
clib2/library/unistd_wildcard_expand.c:                         rc = MatchFirst(arg,ap);
clib2/library/unistd_wildcard_expand.c:                                                 rc = MatchFirst(arg,ap);
vbcc/frontend/vc.c:            if(MatchFirst((STRPTR)convert_path(parm),ap)){
NDK_3.9/Examples/Icon/ConvertMagicWBIcons.c:            error = MatchFirst(str,ap);
NDK_3.9/Examples/Icon/Convert8ColorIcons.c:             error = MatchFirst(str,ap);
NDK_3.9/Examples/Icon/MakeIconsBorderless.c:            error = MatchFirst(str,ap);
NDK_3.9/Examples/Icon/StripIcons.c:             error = MatchFirst(str,ap);
NDK_3.9/Examples/Icon/CondenseIcons.c:          error = MatchFirst(str,ap);
NDK_3.9/Examples/Icon/GlowIconImage.c:          error = MatchFirst(file,ap);
NDK_3.9/Examples/Icon/ConvertNewIcons.c:                error = MatchFirst(str,ap);

[kas1e]

Originally Posted by alkis

Only clib2 seems to reference MatchFirst.
What is your compile/link flags?

The thing i want to port is written on StormC: part C part ASM.

So for C i use "m68k-amigaos-gcc" like this (those as was on StormC at least those whch stll there):

m68k-amigaos-gcc -c obj.c oj obj.o -Wcomment -Wunknown-pragmas -fno-exceptions -funsigned-char -m68020 -msoft-float -O3 -ffast-math -Wimplicit -Wreturn-type -Wno-long-long -Wswitch -Wunused

For asm objects i use vasm:

vasmm68k_mot.exe -Fhunk -nosym -phxass obj.asm -o obj_asm.o

And at the end i link that all like this:

m68k-amigaos-gcc -noixemul -o Game.exe <c_objects> <asm_objects> -lm

[Olaf Barthel]

Originally Posted by kas1e

@All
Is there anything which can bring an warning about "A process called a DOS function with a non longword-aligned Anchor. Function: "MatchFirst()" " even if in the code i didn't have MatchFirst calls at all.

Can it be that link libraries use it inderectly somehow ? Or some other DOS/etc functions may use it under the hood ?

It's either part of the library set you link against your program or in the program itself. Have you generated a map file at the linker stage? It could hint as to where the call came from.

If you are using clib2 then you should be on reasonably safe ground because the OS4 version specifically uses the designated AllocDosObject() function call to create the 'struct AnchorPath' data structure which MatchFirst/MatchNext are using. The only code which makes use of this is in the optional libunix.a file, in "unistd_wildcard_expand.c". The 68k version allocates the 'struct AnchorPath' using the malloc() function. Unless I messed that up (would not be the first time subtle bugs slipped through), it should return a long-aligned pointer address.

[Thomas Richter]

Originally Posted by kas1e

@All
Is there anything which can bring an warning about "A process called a DOS function with a non longword-aligned Anchor. Function: "MatchFirst()" " even if in the code i didn't have MatchFirst calls at all.

Can it be that link libraries use it inderectly somehow ? Or some other DOS/etc functions may use it under the hood ?

The dos.library does not call MatchFirst() internally, but some pattern matching function in your compiler could. This type of problem is typical if the anchor path structure is placed on the stack. This looks more like a problem in one of the compiler support libraries.

[alkis]

The thing is, he is linking with -noixemul which suggests using libnix.
libnix does not reference MatchFirst. The only logical conclusion is that it is referenced from his own object files (either in C and/or asm)

[bebbo]

Originally Posted by bebbo

Well, to be fair: any number is a reasonable stack size. So this sounds reasonable.

coming back to reasonable stack sizes: I found this nice snippet in the gcc code:

  /* Parsing and gimplification sometimes need quite large stack.
     Increase stack size limits if possible.  */
  stack_limit_increase (64 * 1024 * 1024);

[alkis]

Originally Posted by bebbo

coming back to reasonable stack sizes: I found this nice snippet in the gcc code:

  /* Parsing and gimplification sometimes need quite large stack.
     Increase stack size limits if possible.  */
  stack_limit_increase (64 * 1024 * 1024);

64Mb of stack should be enough for everyone.

[bebbo]

I'm announcing an update of amiga-gcc which affects the constructor/init handling and the module versions.

The constructor/init stuff is handled via so called 'stab' entries. The macros are still in place but the implementation will then use named sections which are grouped by the linker scripts. To get these sections working also an end file is needed, to terminate each of these sections with a zero.

Furthermore the libnix auto init code will be changed for baserel and resident code. This is needed to get autoinit working in resident programs, and since resident uses the same libraries as baserel code, this change is for both variants.

So if you are using -noixemul and are building some libraries that use "stabs.h", recompile these once the change is live.

I'll also setup new branches for gcc and binutils (and maybe more). E.g. for binutils there will be a branch named amiga-2.35-branch (or similar) which shifts over to binutils 2.35 and later an amiga-2.38-branch. The imho best one will be the default (see the new file default-repos). To switch to the default, simply remove the '.repos' file and run 'make update-repos'.

I hope some of this is understandable.

[pipper]

Do those changes have an effect on regular programs that don’t specifically interact with the init stuff?
Also, do these individual sections offer better code pruning at link time (I.e. potentially smaller executables)?


Sent from my iPhone using Tapatalk