[debian-mysql] Bug#1006527: mariadb-10.6: FTBFS on ppc64/ppc64el: htmxlintrin.h errors

[Daniel Black]

On Thu, Mar 3, 2022 at 8:16 AM John Paul Adrian Glaubitz
<glaubitz at physik.fu-berlin.de> wrote:
>
> Hello!
>
> On 3/2/22 21:14, Otto Kekäläinen wrote:
> > A recent build regression on ppc64el is preventing a new MariaDB version from migrating from unstable to testing.
> >
> > Could any experts on this list help out?
>
> I don't know where this code is coming from, but this is definitely wrong:
>
> > https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/mysys/CMakeLists.txt#L145
>
> The code is forcing compiler flags based on the architecture and thus overriding the
> baseline. This is a baseline violation and not allowed per Debian Policy.
>
> And, in particular, it violates the baseline of the ppc64 port which is using POWER5,
> not POWER8.

John,

The selective CFLAGS on specific files are there to enable
optimizations in certain functions. Elsewhere in the
code there is runtime detection made of the VSX/vpmsum to actually use the code.

So for POWER5 it should be there but dormant.

Likewise for the bug here. We've got a htmxlintrin.h header insisting
on the -mhtm, backed up the compiler that
doesn't define the __builtin_tbegin builtins without the cflags. We
use the htm target function attribute to compile
specific functions that use it, however the use of instructions is
still behind a runtime check. We can't include the
header check inside a function, otherwise we are defining an inline
function within a function.

My work in progress fix is along these lines:

https://github.com/MariaDB/server/commit/6df3911b61ba669285c08b1456276217c7881292
note just below the standard view of this commit at the bottom, there
is transactional_lock_enabled that does
runtime detection.

But it's still failing
(https://buildbot.mariadb.org/#/grid?branch=bb-10.6-danielblack-MDEV-27936-ppc64-htm-build-fail
, for sid only, and only recent
(https://buildbot.mariadb.org/#/grid?branch=10.6)), proving sid is
true to its name.

If this still violates the policy, I'd like to know now so I can
implement solutions that drop support for ppc64 POWER5+
and support hardware like ppc64le, POWER8+ that we actually do have
hardware for and can support.