Updated Gnu compiler?

@AmigaBlitter

Thats an easy one

The package on OS4Depot is broken

1) In gcc/lib/gcc/ppc-amigaos/5.3.0
2) add a dir called "newlib"
3) copy the "lib" dir that is located in 1) into 2)

Done, but i get the same results

@AmigaBlitter

you might need to erase your appdir settings to make amigaos pick up the new dirs

in a shell:
delete appdir:#?

reboot and try again

@AmigaBlitter

Just to be clear once you are done you should have the newlib library files in a directory called:

GCC:lib/gcc/ppc-amigaos/5.3.0/newlib/lib

Similar to how the clib2 library files are in:

GCC:lib/gcc/ppc-amigaos/5.3.0/clib2/lib

I'm guessing you just copied the contents of the GCC:lib/gcc/ppc-amigaos/5.3.0/lib directory into GCC:lib/gcc/ppc-amigaos/5.3.0/newlib?

@Raziel

Quote:

Or edit the S:startup-sequence and remove APPDIR: from the Path command.

Having APPDIR: in the path list is not a bad idea but it should really be at the end of the path list always and right now that's not the case.

I also have a script S:gcc5-startup which I use to enable the gcc 5.3.0 compiler.

@AmigaBlitter

Oh and be sure to delete "cp" from the gcc install, use the older one instead
cp (coreutils) 5.2.1-9 is known working

cp from gcc5 has a bug (not in the amiga build but i believe in the source itself)

I get an error when using cp in a makefile about not being able to copy something because the file has been replaced in the meantime (which is nonsense, because the file in question doesn't even exist yet...and even if it existed i get the same error)

filed a bug item about that behaviour already

@salass00

Is there going to be a change in AmigaOS4 to make APPDIR: appear last in the path list?

What does your gcc5 startup sequence look like?

@Raziel

Quote:

Don't know. Colin Wenzel would be the person to ask.

Quote:

Just:
Quote:

I didn't write anything into the SDK directory since I don't want to replace a known working compiler setup with what is still a very much experimental version.

The Path change only works if APPDIR: is not in the path list.

Making a script for changing back to the gcc 4.2.4 version should not be too much work.

@salass00

You'rre right. I've missed the final lib dir.

Please check your PM

@salass00

What? and it went unnoticed (no news items) whereas it's the most important news of 2015??? and it's also the most up to date version of GCC! What a surprise!

Thanks Fredrik for the information and thanks to Sbauer for the huge work with this port.

@Elwood

Probably because it's a preliminary/beta release which Sebastian didn't want to stir up before the nastiest bugs are squished...only guessing though

If your're going to try the addtools update, you should definitely back up your existing SDK. The addtools update isn't organized like the OS4 SDK. The OS4 SDK has the coreutils in SDK:local/C and binutils in SDK:gcc/bin. Also, there are additional commands in SDK:local/c. The addtools update has the coreutils and binutils in the SDK/gcc/bin directory. If you don't change the assignments in the SDK:S startup scripts, you could end up with old and new coreutils in the command search paths, If you do change the SDK:S startup scripts, you might lose access to the additional commands in SDK:local/C. In addition the abc-shell "SDK/C/sh" has default command paths that include SDK:local/C which means that old coreutils might still be in the command search path even if the startup-scripts are changed. As people have already pointed out, some libs are in the wrong place and the 'cp' command is bugged.

@xenic

Quote:

Just install the adtools archive into a separate directory next to the SDK and you won't have to back up anything. This is the recommended method for now.

I have a strange ISI exception when using libSDL build with GCC5. Stack trace points to this line:

https://github.com/capehill/os4sdl/blo ... aos4/SDL_systhread.c#L165

Code never reaches plistInit() function according to serial debug. Looks like it jumps to wrong address instead of? I guess I have to try to investigate the generated code, but perhaps somebody already knows what might be wrong?

(0x5B526C80) 0x6FA0D8A4 [cannot decode symbol]
(0x5B526CB0) Beta41:SObjs/libSDL-1.2.so:_INIT_thread_init()+0xf0 (section 12 @ 0x778)
(0x5B526CD0) native kernel module Kickstart/elf.library.kmod+0x0000552c
(0x5B526D00) native kernel module Kickstart/newlib.library.kmod+0x00001f40
(0x5B526D70) native kernel module Kickstart/newlib.library.kmod+0x00002d14
(0x5B526F10) native kernel module Kickstart/newlib.library.kmod+0x00002ef0
(0x5B526F50) a.out:_start()+0x170 (section 8 @ 0x68C)
(0x5B526F90) native kernel module Kickstart/dos.library.kmod+0x00025c54
(0x5B526FC0) native kernel module Kickstart/kernel+0x00039894
(0x5B526FD0) native kernel module Kickstart/kernel+0x000398dc

@salass00
You might also want to check the coreutils that are renamed in SDK:local/C but not renamed in the addtools coreutils. I'm not sure but if you use the coreutils 'date' or 'dir' commands when compiling in an Amiga shell, they might end up in APPDIR: and cause problems for Amiga scripts etc.

Tried the delete APPDIR:#? and the copy newlib into the new adtools but still

gcc:ppc-amigaos/bin/ld: cannot find -lgcc
gcc:ppc-amigaos/bin/ld: cannot find -lgcc_eh

@zzd10h

1) Start "Find"
2) Point it to your GCC: dir
3) Type "gcc_eh" in the "Pattern" field
4) Let it run and post your result

Should be two instances found:
GCC:lib/gcc/ppc-amigaos/5.3.0/clib2/lib//libgcc_eh.a
GCC:lib/gcc/ppc-amigaos/5.3.0/newlib/lib//libgcc_eh.a

@xenic

Quote:

I don't have APPDIR: in the command path and I don't have any scripts that use APPDIR:date or APPDIR:dir.

@Raziel

Thank you but finally I succeeded by

1) renaming my SDK:gcc/bin/gcc to gcc.OLD
2) changing my CC in my MakeFile from SDK:gcc/bin to GCC:bin/gcc

compilation OK !

@zzd10h

I did it similar but without the renaming

i moved the old gcc dir out of sdk and installed the new, deleted APPDIR: entries and rebooted