Reason: https://gitlab.kitware.com/cmake/cmake/issues/19590
Our workaround within cmake is not sufficient as it does not
address the issue fully and things still break sometimes. So
work around this in the build-style for the time being (and
drop the cmake patch).
Once this is fixed upstream (probably needs special casing
for the -pipe flag and strip it during compile tests) we
can drop this.
ppc is the correct name which cmake reports in a native ppc32
environment, therefore the cross toolchain definition is wrong.
Closes: #12061 [via git-merge-pr]
Signed-off-by: Jürgen Buchmüller <pullmoll@t-online.de>
This reverts commit 6638dc5526.
Setting RelWithDebInfo can cause issues since cmake macros often handle
only Release or Debug build but not RelWithDebInf which might cause
issues https://github.com/void-linux/void-packages/pull/10948
It is advised to set -DCMAKE_BUILD_TYPE=RelWithDebInfo manually in
packages that ignore our CFLAGS or patch them to use them
closes#10948
This adds the build profiles for ppc64 targets as well as
modifications in other parts of the infra.
These targets are supported:
- ppc64le (glibc little endian elfv2)
- ppc64le-musl (musl little endian)
- ppc64-musl (musl big endian)
ELFv1 targets are explicitly not supported at this point.
Big endian musl supports ppc 970 or newer, while little endian
targets are set to a generic powerpc64le which effectively means
POWER8 and newer. Tuning is always set for POWER9, which is the
most likely target hardware. We also make sure AltiVec is always
on, because it is supported on all hardware we target.
[ci skip]
Many packages depending on Qt5 or Qt4 and built with cmake
generate "flags.make" files with -isystem for include paths.
With gcc6 this results in e.g. "#include_next <stdlib.h>" giving
an error, because a -isystem /usr/include is in the wrong place.
The simple fix is to replace "-isystem" with just "-I".
