Sergei Golubchik, a warning referred as dpkg-buildflags-missing is about missing "-fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security". You added most of these flags in 10.1. Is it reasonable to backport it to 10.0?

Otto Kekäläinen, if we consider this risky to backport to 10.0, you may have to add these flags to debian build scripts to fix this warning. compiler-flags-hidden is most probably false positive. But it is hard to say until dpkg-buildflags-missing is fixed.

shlibs-symbol-not-found happens on ARM, which I believe is not among of our supported platforms. I'd fix it anyway, but we have no ARM for debugging.

compiler-flags-hidden is false positive. Running blhc manually yields

NONVERBOSE BUILD: [  7%] Building C object mysys/CMakeFiles/mysys.dir/my_open.c.o
NONVERBOSE BUILD: [  7%] Building C object mysys/CMakeFiles/mysys.dir/my_pread.c.o

This is, obviously, a blhc bug. Real compiler lines for these files come later in the log.

dpkg-buildflags-missing looks like a packaging issue? Somehow Debian hardening flags aren't passed down to the compiler. Our cmake files certainly don't strip these flags away.

shlibs-symbol-not-found looks suspiciously similar to a documented dpkg-shlibdeps bug. Quoting https://qa.debian.org/bls/bytag/W-shlibs-symbol-not-found.html

Possible reasons:
...

• a special symbol dpkg-shlibs had not yet in its blacklist.
  Currntly known is __aeabi_unwind_cpp_pr1@GCC_3.5, which can be ignored on armel and armhf.

And we have the warning about __aeabi_atexit@CXXABI_ARM_1.3.3 on armel and armhf.

Conclusion: these all are downstream (Debian) packaging issues, no upstream (MariaDB) changes are needed.