question about default CXXFLAGS, LDFLAGS and oter FOOFLAGS used to build ps2toolchain

[sl1pkn07]

Hi. I see un the scrips, for example:

https://github.com/ps2dev/ps2toolchain-ee/blob/main/scripts/001-binutils.sh#L47

uses a systemwide CFLAGS/LDFLAGS and other flags for build the toolchain. but not all SO/Distributions uses the same; Ubuntu uses ones, msys2 use others, archlinux other (my distribution), Suse other, etc etc

build the toolchain in differents SO means uses different flags wich lead to make the toolchains with different behavior

if the toolchains is builded for PC target should not be a problem, but when build things for PS2 may lead undefined behavior, or success compilations in one and failed in others

this is ok?

i think in this case (PS2 target) should be use the same XXflags in all systems (hardcoded the flags in the scripts), and not use the own SO ones

greetings

[fjtrujy]

Hello, I don't really understand what you mean. Flags are automatically filled by configure having in mind obviously the OS you are using. They CANT be always the same for all OS, maybe there is a flag which is just needed by MacOS, so that flag will be added by the configure if you are running in MacOs

We have proved that toolchain is working perfectly in Alpine, Ubuntu, Fedora, MacOS and Windows, I'm not sure if Arch distributions have issues because we never tried it.

[sl1pkn07]

Hi

FIXED newlib error

the old toolchain works in arch. i have used in it several years without aparental problem. but with new toolchain versions. fails. for example newlib ee: ~~~ mips64r5900el-ps2-elf-gcc -B/tmp/makepkg/ps2-newlib/src/build-newlib-ee/mips64r5900el-ps2-elf/newlib/ -isystem /tmp/makepkg/ps2-newlib/src/build-newlib-ee/mips64r5900el-ps2-elf/newlib/targ-include -isystem /tmp/makepkg/ps2-newlib/src/newlib/newlib/libc/include -B/tmp/makepkg/ps2-newlib/src/build-newlib-ee/mips64r5900el-ps2-elf/libgloss/mips -L/tmp/makepkg/ps2-newlib/src/build-newlib-ee/mips64r5900el-ps2-elf/libgloss/libnosys -L/tmp/makepkg/ps2-newlib/src/newlib/libgloss/mips -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"4.1.0\" -DPACKAGE_STRING=\"newlib\ 4.1.0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I. -I../../../../../../newlib/newlib/libc/machine/mips -fno-builtin -DMISSING_SYSCALL_NAMES -DHAVE_INIT_FINI -fno-builtin -DMISSING_SYSCALL_NAMES -DHAVE_INIT_FINI -D_COMPILING_NEWLIB -O2 -c -o lib_a-memcpy.o `test -f 'memcpy.S' || echo '../../../../../../newlib/newlib/libc/machine/mips/'`memcpy.S ../../../../../../newlib/newlib/libc/machine/mips/setjmp.S: Assembler messages: ../../../../../../newlib/newlib/libc/machine/mips/setjmp.S:131: Error: opcode not supported on this processor: r5900 (mips3) `sdc1 $f20,((0+11)*8)($4)' ../../../../../../newlib/newlib/libc/machine/mips/setjmp.S:131: Error: opcode not supported on this processor: r5900 (mips3) `sdc1 $f22,((1+11)*8)($4)' ../../../../../../newlib/newlib/libc/machine/mips/setjmp.S:131: Error: opcode not supported on this processor: r5900 (mips3) `sdc1 $f24,((2+11)*8)($4)' ../../../../../../newlib/newlib/libc/machine/mips/setjmp.S:131: Error: opcode not supported on this processor: r5900 (mips3) `sdc1 $f26,((3+11)*8)($4)' ../../../../../../newlib/newlib/libc/machine/mips/setjmp.S:131: Error: opcode not supported on this processor: r5900 (mips3) `sdc1 $f28,((4+11)*8)($4)' ../../../../../../newlib/newlib/libc/machine/mips/setjmp.S:131: Error: opcode not supported on this processor: r5900 (mips3) `sdc1 $f30,((5+11)*8)($4)' ../../../../../../newlib/newlib/libc/machine/mips/setjmp.S:149: Error: opcode not supported on this processor: r5900 (mips3) `ldc1 $f20,((0+11)*8)($4)' ../../../../../../newlib/newlib/libc/machine/mips/setjmp.S:149: Error: opcode not supported on this processor: r5900 (mips3) `ldc1 $f22,((1+11)*8)($4)' ../../../../../../newlib/newlib/libc/machine/mips/setjmp.S:149: Error: opcode not supported on this processor: r5900 (mips3) `ldc1 $f24,((2+11)*8)($4)' ../../../../../../newlib/newlib/libc/machine/mips/setjmp.S:149: Error: opcode not supported on this processor: r5900 (mips3) `ldc1 $f26,((3+11)*8)($4)' ../../../../../../newlib/newlib/libc/machine/mips/setjmp.S:149: Error: opcode not supported on this processor: r5900 (mips3) `ldc1 $f28,((4+11)*8)($4)' ../../../../../../newlib/newlib/libc/machine/mips/setjmp.S:149: Error: opcode not supported on this processor: r5900 (mips3) `ldc1 $f30,((5+11)*8)($4)' make[6]: *** [Makefile:264: lib_a-setjmp.o] Error 1 make[6]: *** Se espera a que terminen otras tareas.... ~~~ i completely sure is because the flags is not correcty setted, and this is because each distribution uses the own flags

for example, arch, in the package build system uses this CFLAGS/CXXFLAGS/etc by default

CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions \
        -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security \
        -fstack-clash-protection -fcf-protection"
CXXFLAGS="$CFLAGS -Wp,-D_GLIBCXX_ASSERTIONS"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"

this flags is used in all packages in the distribution. obiulsly, not all flags setted avobe woks with the iop,ee and dvp targets, and not works with older toolchains for that i disable in the flags environment and lead the build scripts uses the hardcoded ones, but in the project build scripts, is hardcoded a little set of them

as i said, each distributions uses the own internal common set of flags , and other diferent OS (win and mac) other different, but the compiler use a generic set of them wich works in all SO (is use the same compiler, gcc in this case), but is not setted in the scripts

i think is better set all common flags in the scrips instead lead the distribution uses the internal ones

sorry. my english is catastrophic. i see you are spanish like me, i cant talk with you in spanish in the discord channel if you want :)

greetings

EDIT: fixed the error in newlib. when clone the repo i just use the playn newlib instead the ee-v4.1.0 branch :tsk: . but the question of the flags is still available

[uyjulian]

This doesn't seem to be an issue anymore. Reopen if this is not the case