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

Current complaints are:

Issues found in current buildd logs for mariadb-10.0:

W compiler-flags-hidden 10 (of 3746) hidden (kfreebsd-amd64)

W compiler-flags-hidden 15 (of 3750) hidden (i386)

W compiler-flags-hidden 2 (of 3549) hidden (mips, s390x)

W compiler-flags-hidden 2 (of 3750) hidden (mipsel)

W compiler-flags-hidden 212 (of 3549) hidden (ppc64)

W compiler-flags-hidden 24 (of 3750) hidden (arm64)

W compiler-flags-hidden 4 (of 3549) hidden (m68k)

W compiler-flags-hidden 54 (of 3750) hidden (ppc64el)

W compiler-flags-hidden 6 (of 3549) hidden (powerpcspe)

W compiler-flags-hidden 6 (of 3750) hidden (armel, armhf)

W compiler-flags-hidden 7 (of 3750) hidden (mips64el)

W compiler-flags-hidden 8 (of 3549) hidden (powerpc)

W compiler-flags-hidden 8 (of 3746) hidden (kfreebsd-i386)

W shlibs-symbol-not-found (armel, armhf)

(from https://qa.debian.org/bls/packages/m/mariadb-10.0.html)

current: https://qa.debian.org/bls/packages/m/mariadb-10.5.html

agree compiler-flags-hidden is a packaging issue. cmake can expose verbose logs and it doesn't look particularly obscured.

shlib-symbols-not-found occurs on unsupported arm architectures. They still references __aeabi_atexit@CXXABI_ARM_1.3.3.

probably relates is:
https://gcc.gnu.org/onlinedocs/gccint/C_002b_002b-ABI.html
around TARGET_CXX_USE_AEABI_ATEXIT

related to the two instances of atexit in the codebase:

mysys/safemalloc.c:    atexit(sf_terminate);

storage/mroonga/vendor/groonga/src/groonga.c:      if (atexit(config_file_clear)) {

As its an internal function, it look like you should just compile with -fuse-cxa-atexit on these platforms.

compiler-flags-hidden might also be, based one the output Sergei observed years ago, mitigated by using cmake --build . --verbose (using tools like they designed and documented, very radical). This, like make --output-sync=target, keeps the output of the compile output to one complete step rather than letting multiple compile processes write to the same stdout.