Marko Mäkelä added a comment - 2020-06-11 13:01 I think that we should primarily address this by trying to update the compiler, like we recently did on POWER. If that is really impossible, we could add some preprocessor magic to lower the optimization level or to simplify some code. The build failure is most likely related to the increased the use of inline functions that access std::atomic data, in MDEV-15053 .

Daniel Bartholomew added a comment - 2020-06-11 16:38 marko and serg Which gcc version should I go with? We don't want to introduce new incompatibilities, but this might be a chance to have at least one builder with a much more modern toolchain. For reference, on the centos74-aarch64-build VM we currently have: gcc 4.8.5-16, binutils 2.27-11, and cmake 3.14.0

Daniel Bartholomew added a comment - 2020-06-11 18:18 - edited Tried a test build with cmake . -DBUILD_CONFIG=mysql_release -DCMAKE_COMMAND_DEP=cmake -DRPM=centos74 -O2 , but that didn't work. Same error as in the description. I'll try some builds editing out a workaround to see if that helps, and I'll also try with a newer gcc.

Daniel Bartholomew added a comment - 2020-06-11 21:29 When using gcc 4.9.4, the main part of the build completes, but the cpack packaging step fails with the following: *** ERROR: No build ID note found in /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/build/_CPack_Packages/Linux/RPM/mariadb-10.5.4-linux-aarch64/backup/usr/bin/mariadb-backup error: Bad exit status from /var/tmp/rpm-tmp.e9nNab (%install) Bad exit status from /var/tmp/rpm-tmp.e9nNab (%install) *** CPackRPM:Debug: - /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/build/_CPack_Packages/Linux/RPM/rpmbuildMariaDB-backup.out CPackRPM:Debug: *** Building target platforms: aarch64 Building for target aarch64 Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.XJe7pa Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.e9nNab extracting debug info from /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/build/_CPack_Packages/Linux/RPM/mariadb-10.5.4-linux-aarch64/backup/usr/bin/mariadb-backup     RPM build errors: *** CMake Error at /usr/local/share/cmake-3.14/Modules/Internal/CPack/CPackRPM.cmake:1799 (message): RPM package was not generated! /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/build/_CPack_Packages/Linux/RPM Call Stack (most recent call first): /usr/local/share/cmake-3.14/Modules/Internal/CPack/CPackRPM.cmake:1870 (cpack_rpm_generate_package) /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/build/cmake/Internal/CPack/CPackRPM.cmake:54 (include)

Daniel Bartholomew added a comment - 2020-06-12 18:04 Looks like the errors are fixed in the latest pushes into 10.5: https://buildbot.askmonty.org/buildbot/builders/kvm-rpm-centos74-aarch64/builds/8265

Daniel Bartholomew added a comment - 2020-06-12 18:38 I'm guessing this commit from marko is what fixed it.

Marko Mäkelä added a comment - 2020-06-13 04:57 Yes, it seems that MDEV-15053 caused this build failure by making more code inline and by expanding the use of std:atomic . Apparently, that resulted in some expanded functions being too large for the old compiler to handle on the ARMv8 target. MDEV-22877 probably fixed this by replacing the inline function buf_page_hash_get_locked() and by eliminating some redundant invocations of buf_pool_t::page_hash_lock<false>() . Those calls were never needed when the caller is already holding buf_pool.mutex .