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

[Tom Grzybowski]

> 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.


If that happens, all of us with Power5 and Power4 CPS would be dropped from Debian!


Thomas Grzybowski


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, March 2, 2022 10:17 PM, Daniel Black <daniel at mariadb.org> wrote:

> 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.