mariadb106-client fails to build on NetBSD 10 aarch64

[Greg Troxel <gdt%lexort.com@localhost>]

(I'm using 2025Q4, but I think pkgsrc-current is the same.  Everything
else is up to date, except mess from p5-DBD-mysql desupportting mariadb
and not being replaced by p5-DBD-mariadb yet.)

On a RPI4, running netbsd-10 from early December:



[ 59%] Building C object libmariadb/libmariadb/CMakeFiles/mariadb_obj.dir/ma_context.c.o
cd /tmp/work/databases/mariadb106-client/work/mariadb-10.6.23/libmariadb/libmariadb && /tmp/work/databases/mariadb106-client/work/.cwrapper/bin/gcc -DHAVE_CONFIG_H -DHAVE_OPENSSL -DHAVE_REMOTEIO=1 -DHAVE_TLS -DLIBICONV_PLUG -DMARIADB_MACHINE_TYPE=\"aarch64\" -DMARIADB_SYSTEM_TYPE=\"NetBSD\" -I/tmp/work/databases/mariadb106-client/work/mariadb-10.6.23/libmariadb/include -I/tmp/work/databases/mariadb106-client/work/mariadb-10.6.23/libmariadb/plugins/auth -I/tmp/work/databases/mariadb106-client/work/mariadb-10.6.23/libmariadb/plugins/compress -I/tmp/work/databases/mariadb106-client/work/mariadb-10.6.23/libmariadb/plugins/pvio -I/tmp/work/databases/mariadb106-client/work/mariadb-10.6.23/libmariadb/libmariadb -I/usr/pkg/include -O2 -DIOAPI_NO_64 -DNO_STATIC_MODULES -DNO_STATIC_MODULES -I/usr/pkg/include -Dz_off_t=long -I/usr/include -I/usr/pkg/include/libxml2 -I/usr/include/krb5 -I/usr/include/readline -moutline-atomics -Wunused -Wlogical-op -Wno-uninitialized -Wall -Wextra -Wformat-security -Wno-init-self -Wwrite-strings -Wshift-count-overflow -Wdeclaration-after-statement -Wno-undef -Wno-unknown-pragmas -Wno-stringop-truncation -DNDEBUG -DDBUG_OFF -DDBUG_OFF -std=gnu99   -DNO_STATIC_MODULES -DNO_STATIC_MODULES -I/usr/pkg/include -Dz_off_t=long -I/usr/include -I/usr/pkg/include/libxml2 -I/usr/include/krb5 -I/usr/include/readline -D HAVE_COMPRESS -D LIBMARIADB -D THREAD -fPIC -MD -MT libmariadb/libmariadb/CMakeFiles/mariadb_obj.dir/ma_context.c.o -MF CMakeFiles/mariadb_obj.dir/ma_context.c.o.d -o CMakeFiles/mariadb_obj.dir/ma_context.c.o -c /tmp/work/databases/mariadb106-client/work/mariadb-10.6.23/libmariadb/libmariadb/ma_context.c
/tmp//cc11LXZf.s: Assembler messages:
/tmp//cc11LXZf.s:43: Error: selected processor does not support `bti j'
/tmp//cc11LXZf.s:49: Error: selected processor does not support `bti j'
/tmp//cc11LXZf.s:129: Error: selected processor does not support `bti j'
/tmp//cc11LXZf.s:144: Error: selected processor does not support `bti j'
/tmp//cc11LXZf.s:223: Error: selected processor does not support `bti j'
*** [libmariadb/libmariadb/CMakeFiles/mariadb_obj.dir/ma_context.c.o] Error code 1



It's using system gcc 10, which reports

Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/libexec/lto-wrapper
Target: aarch64--netbsd
Configured with: /usr/src/tools/gcc/../../external/gpl3/gcc/dist/configure --target=aarch64--netbsd --enable-long-long --enable-threads --with-bugurl=http://www.NetBSD.org/support/send-pr.html --with-pkgversion='NetBSD nb2 20230710' --with-system-zlib --without-isl --enable-__cxa_atexit --enable-libstdcxx-time=rt --enable-libstdcxx-threads --with-diagnostics-color=auto-if-env --enable-fix-cortex-a53-835769 --enable-fix-cortex-a53-843419 --with-default-libstdcxx-abi=new --with-mpc-lib=/var/obj/mknative/evbarm-aarch64/usr/src/external/lgpl3/mpc/lib/libmpc --with-mpfr-lib=/var/obj/mknative/evbarm-aarch64/usr/src/external/lgpl3/mpfr/lib/libmpfr --with-gmp-lib=/var/obj/mknative/evbarm-aarch64/usr/src/external/lgpl3/gmp/lib/libgmp --with-mpc-include=/usr/src/external/lgpl3/mpc/dist/src --with-mpfr-include=/usr/src/external/lgpl3/mpfr/dist/src --with-gmp-include=/usr/src/external/lgpl3/gmp/lib/libgmp/arch/aarch64 --enable-tls --disable-multilib --disable-libstdcxx-pch --build=aarch64--netbsd --host=aarch64--netbsd --with-sysroot=/var/obj/mknative/evbarm-aarch64/usr/src/destdir.evbarm
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.5.0 (nb3 20231008) 

BTI seems to be present on some aarch64 processors and not others, or
perhaps only does something on some.

Reading the code, the bti instruction memonically is useed on gcc >= 9.1
and a hand-assembled opcode is used otherwise.  I locally patched that
to gcc > 10, so it would use the opcode.  That allowed the build to
continute.   Replacing the package and rebooting, mariadb still works.




What's the right fix?

My inclination is to force off MY_CONTEXT_USE_AARCH64_GCC_ASM on the
theory that the plan to use asm on aarch64 is unreliable.  My other
inclination is to patch to require gcc >=11 before the bti mnemonic is
used.

Before that, I'd like to give people that understand this better a
chance to propose a better fix.