Add ppc64le and s390x to recognized architectures

[kleisauke]

See for example:
https://github.com/kleisauke/libvips-packaging/actions/runs/20065009063/job/57551203630
https://github.com/kleisauke/libvips-packaging/actions/runs/20065009063/job/57551203641

Note that I considered adding architecture-specific compile flags, similar to what's done here:

libultrahdr/CMakeLists.txt

Lines 295 to 323 in 8cbc983

	if(ARCH STREQUAL "i386")
	add_compile_options(-m32)
	add_compile_options(-march=i386)
	add_compile_options(-mtune=generic)
	elseif(ARCH STREQUAL "amd64")
	add_compile_options(-m64)
	add_compile_options(-march=x86-64)
	add_compile_options(-mtune=generic)
	elseif(ARCH STREQUAL "arm")
	add_compile_options(-march=armv7-a)
	add_compile_options(-marm)
	if(NOT ANDROID_ABI)
	add_compile_options(-mfloat-abi=hard)
	endif()
	add_compile_options(-mfpu=neon-vfpv3)
	add_compile_options(-fno-lax-vector-conversions)
	elseif(ARCH STREQUAL "aarch64")
	add_compile_options(-march=armv8-a)
	add_compile_options(-fno-lax-vector-conversions)
	elseif(ARCH STREQUAL "riscv64")
	add_compile_options(-march=rv64gc)
	add_compile_options(-mabi=lp64d)
	elseif(ARCH STREQUAL "riscv32")
	add_compile_options(-march=rv32gc)
	add_compile_options(-mabi=ilp32d)
	elseif(ARCH STREQUAL "loong64")
	add_compile_options(-march=loongarch64)
	add_compile_options(-mabi=lp64d)
	endif()

However, I don't think that makes much sense, as Linux distributions usually handle this themselves.

[kleisauke]

Alternatively, here's a changeset that removes the platform and architecture detection logic (including the arch-specific flags):
main...kleisauke:remove-platform-arch-detect

For example, this allows building for a Raspberry Pi Zero W (ARMv6). Without this change, the build fails with:

cc1plus: warning: switch '-mcpu=arm1176jzf-s' conflicts with '-march=armv7-a' switch
Assembler messages:
Error: unknown floating point format `neon-vfpv3'

(and this is just one case, there are likely better examples of why injecting those flags is not advisable)

[kmilos]

there are likely better examples of why injecting those flags is not advisable

FWIW, build on Fedora 43 w/ GCC 15 fails w/

/usr/bin/ld: /tmp/ccdT2utQ.ltrans0.ltrans.o: in function `std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()':
/usr/include/c++/15/ext/atomicity.h:68:(.text+0x2ce8): undefined reference to `__atomic_fetch_add_4'
/usr/bin/ld: /usr/include/c++/15/ext/atomicity.h:68:(.text+0x2d3c): undefined reference to `__atomic_fetch_add_4'

presumably because the forced -march=i386 overrides the distribution set -march=i686 CFLAGS...? @topazus

Interestingly, linking luckily works out w/ the newer GCC 16 toolchain in Fedora 44 - I guess it now somehow figures out better it actually needs to link libatomic (although both have the -Wl,--as-needed flag)... (Note that in reality libatomic would be unnecessary in this case for i686.)

[topazus]

Interestingly, linking luckily works out w/ the newer GCC 16 toolchain in Fedora 44 - I guess it now somehow figures out better it actually needs to link libatomic (although both have the -Wl,--as-needed flag)... (Note that in reality libatomic would be unnecessary in this case for i686.)

It may be related to automatic linking of libatomic in GCC 16. ref: gcc-mirror/gcc@e63cf4b

[kmilos]

@topazus I feel the alternative of removing -march=i386 for all Fedora versions might be better than explicitly asking for -latomic conditionally?

[kleisauke]

Closing in favor of #383.