All check 64 bit based on 64 appearing in @@version_compile_machine. On s390x this isn't the case.
version_compile_machine is derived from SYSTEM_TYPE which though a lot of hackery in cmake/package_name.cmake defines PLATFORM. In s390x's case this is based on CMAKE_SYSTEM_PROCESSOR which in the unix case is from uname -m. On s390x this is exactly "s390x" hence no-match and therefore 32 bit (which is definitely not the case).
As most of the mtr tests that use this macro are using it because of the UINT_MAX value used in system variable, lets use that as the test case for 32 vs 64 bit.
All check 64 bit based on 64 appearing in @@version_compile_machine. On s390x this isn't the case.
version_compile_machine is derived from SYSTEM_TYPE which though a lot of hackery in cmake/package_name.cmake defines PLATFORM. In s390x's case this is based on CMAKE_SYSTEM_PROCESSOR which in the [[https://cmake.org/cmake/help/latest/variable/CMAKE_HOST_SYSTEM_PROCESSOR.html#unix-platforms|unix case] is from {{uname -m}}. On s390x this is exactly "s390x" hence no-match and therefore 32 bit (which is definitely not the case).
As most of the mtr tests that use this macro are using it because of the UINT_MAX value used in system variable, lets use that as the test case for 32 vs 64 bit.
All check 64 bit based on 64 appearing in @@version_compile_machine. On s390x this isn't the case.
version_compile_machine is derived from SYSTEM_TYPE which though a lot of hackery in cmake/package_name.cmake defines PLATFORM. In s390x's case this is based on CMAKE_SYSTEM_PROCESSOR which in the [unix case|https://cmake.org/cmake/help/latest/variable/CMAKE_HOST_SYSTEM_PROCESSOR.html#unix-platforms] is from {{uname -m}}. On s390x this is exactly "s390x" hence no-match and therefore 32 bit (which is definitely not the case).
As most of the mtr tests that use this macro are using it because of the UINT_MAX value used in system variable, lets use that as the test case for 32 vs 64 bit.
Looking at cmake/package_name.cmake it is apparent that the intent of DEFAULT_PLATFORM define is to contain "64" if the platform is 64 bit.
See for example how AIX os is handled:
IF(NOT 64BIT AND CMAKE_SYSTEM_PROCESSOR MATCHES "^mips64")
...
Just do a similar check for S390x and append -64bit at the end (or always append 64bit at the end for s390x). No reason to couple the 64bit check to a system variable meant for a completely different purpose. It becomes much more likely to break the 64 bit check if for some strange reason, the valid range of the system variable changes.
Side note:
Reading cmake/package_name.cmake, there might be a similar problem with OS X too, but I can not check that presently.
Vicențiu Ciorbaru
added a comment - Looking at cmake/package_name.cmake it is apparent that the intent of DEFAULT_PLATFORM define is to contain "64" if the platform is 64 bit.
See for example how AIX os is handled:
ELSEIF(CMAKE_SYSTEM_NAME MATCHES "AIX")
SET(DEFAULT_PLATFORM "${CMAKE_SYSTEM_NAME}5.${CMAKE_SYSTEM_VERSION}")
IF(64BIT)
SET(DEFAULT_MACHINE "${CMAKE_SYSTEM_PROCESSOR}-64bit")
ENDIF()
Also for "exotic mips"
IF(NOT 64BIT AND CMAKE_SYSTEM_PROCESSOR MATCHES "^mips64")
...
Just do a similar check for S390x and append -64bit at the end (or always append 64bit at the end for s390x). No reason to couple the 64bit check to a system variable meant for a completely different purpose. It becomes much more likely to break the 64 bit check if for some strange reason, the valid range of the system variable changes.
Side note:
Reading cmake/package_name.cmake , there might be a similar problem with OS X too, but I can not check that presently.
Looking at cmake/package_name.cmake it is apparent that the intent of DEFAULT_PLATFORM define is to contain "64" if the platform is 64 bit.
See for example how AIX os is handled:
ELSEIF(CMAKE_SYSTEM_NAME MATCHES "AIX")
SET(DEFAULT_PLATFORM "${CMAKE_SYSTEM_NAME}5.${CMAKE_SYSTEM_VERSION}")
IF(64BIT)
SET(DEFAULT_MACHINE "${CMAKE_SYSTEM_PROCESSOR}-64bit")
ENDIF()
Also for "exotic mips"
IF(NOT 64BIT AND CMAKE_SYSTEM_PROCESSOR MATCHES "^mips64")
...
Just do a similar check for S390x and append -64bit at the end (or always append 64bit at the end for s390x). No reason to couple the 64bit check to a system variable meant for a completely different purpose. It becomes much more likely to break the 64 bit check if for some strange reason, the valid range of the system variable changes.
Side note:
Reading cmake/package_name.cmake, there might be a similar problem with OS X too, but I can not check that presently.