Bug #48078
closedHAVE_UNALIGNED_ACCESS
0%
Description
This is seen when using './make-srpm.sh' on Fedora 32 and running a subsequent
'rpmbuild -ba' on the source rpm produced.
-- Performing Test HAVE_UNALIGNED_ACCESS - Failed CMake Error at cmake/modules/CephChecks.cmake:140 (message): Unaligned access is required Call Stack (most recent call first): CMakeLists.txt:95 (include)
The actual fatal error reported in CMakeError.log is the following.
Compiler executable checksum: 61a79f744777569dee61fe7e7cf9806a In file included from /usr/include/c++/10/ext/string_conversions.h:41, from /usr/include/c++/10/bits/basic_string.h:6535, from /usr/include/c++/10/string:55, from /usr/include/c++/10/bits/locale_classes.h:40, from /usr/include/c++/10/bits/ios_base.h:41, from /usr/include/c++/10/streambuf:41, from /usr/include/c++/10/bits/streambuf_iterator.h:35, from /usr/include/c++/10/iterator:66, from /home/brad/working/rpmbuild/BUILD/ceph-15.0.0-19450-ga0e82efeea6/build/CMakeFiles/CMakeTmp/src.cxx:3: /usr/include/c++/10/cstdlib:75:15: fatal error: stdlib.h: No such file or directory 75 | #include_next <stdlib.h> | ^~~~~~~~~~ compilation terminated.
I could not reproduce this on the same machine doing a build 'in tree' even with
identical arguments to cmake, g++, etc.
After some head scratching I added the following patch and started a new build.
diff --git a/cmake/modules/CephChecks.cmake b/cmake/modules/CephChecks.cmake index ca86dcbc73d..a5487520991 100644 --- a/cmake/modules/CephChecks.cmake +++ b/cmake/modules/CephChecks.cmake @@ -96,7 +96,7 @@ CHECK_STRUCT_HAS_MEMBER("struct stat" st_mtimespec.tv_nsec sys/stat.h if(NOT CMAKE_CROSSCOMPILING) include(CheckCXXSourceRuns) cmake_push_check_state() - set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -std=c++17") + set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -v -std=c++17") if(WIN32) set(CMAKE_REQUIRED_LIBRARIES ws2_32) endif()
This shows the issue is related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129 I believe.
Failed build extract from CMakeError.log done under 'rpmbuild'.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Versions of loaded plugins: annobin: Version ANNOBIN_VERSION ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/10/include-fixed" ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/10/../../../../x86_64-redhat-linux/include" ignoring duplicate directory "/usr/include" ignoring duplicate directory "/usr/include" as it is a non-system directory that duplicates a system directory #include "..." search starts here: #include <...> search starts here: /usr/include /usr/lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10 /usr/lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/x86_64-redhat-linux /usr/lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/backward /usr/lib/gcc/x86_64-redhat-linux/10/include /usr/local/include End of search list.
Output from a successful build.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/10/include-fixed" ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/10/../../../../x86_64-redhat-linux/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10 /usr/lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/x86_64-redhat-linux /usr/lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/backward /usr/lib/gcc/x86_64-redhat-linux/10/include /usr/local/include /usr/include End of search list.
Note the differences in the search list with '/usr/include' at the end in the
successful build and the beginning for the failed build and the references to
'ignoring duplicate directory "/usr/include"' in the failed case.
Updated by Brad Hubbard over 3 years ago
This does not reproduce on copr, nor locally using mock so I assume this is an issue with rpms (possibly to do with rpm macros) installed in the environment where this is seen. The recommended workaround is to use mock to build your rpms.
Updated by Brad Hubbard over 2 years ago
For anyone who encounters this I hit it again today and worked out it was being caused by having flatpak-rpm-macros installed as it sets various environment variables for (apparently all) builds such as CPLUS_INCLUDE_PATH. Did that take some finding!