+++ This bug was initially created as a clone of Bug #1474743 +++
Description of problem:
The latest update of Ceph in rawhide just excluded several Fedora architectures
ExcludeArch: i686 armv7hl ppc64
As a result this has broken downstream packages that depend on ceph like libvirt & QEMU.
Please re-enable these architectures asap.
If there are build problems then plesae create blocker bugs against the arch exclude trackers
Version-Release number of selected component (if applicable):
--- Additional comment from Kaleb KEITHLEY on 2017-07-25 07:22:38 EDT ---
It doesn't build on those platforms.
File a bug against Ceph.
--- Additional comment from Daniel Berrange on 2017-07-25 07:29:19 EDT ---
That's not the way Fedora works. As per the packaging guidelines link above, maintainers need to explicitly track any build problems on architectures & mark them as blocking the arch trackers so the problem can be resolved.
see build log at
It looks like the core problem with PPC64 is that we've not set HAVE_POWER8 in the cmake rules. So the source code is using #ifdef __powerpc__ to enable ppc specific code, but the cmake if HAVE_POWER8 rules are all evaluating to false, so we get link errors.
Adding something like the following to cmake/modules/SIMDExt.cmake
+elseif(CMAKE_SYSTEM_PROCESSOR MATCHES "(powerpc|ppc)64")
+ set(HAVE_PPC64 1)
+ message(STATUS " we are ppc64")
+ CHECK_C_COMPILER_FLAG("-mcpu=power8" HAVE_POWER8)
+ message(STATUS " HAVE_POWER8 yes")
should get it closer to building successfully, but I've not tested this - this is just from observation of what's failed in that link above
Al, are you familiar with this build failure?
(In reply to Ken Dreyer (Red Hat) from comment #3)
> Al, are you familiar with this build failure?
It looks familiar, but may not be exactly what I've seen. The first thing I would try is fixing the spec file; these lines in the log --
Manually-specified variables were not used by the project:
are from a typo, so s/WTIH_BABELTRACE/WITH_BABELTRACE/g. Even if it doesn't fix the problem, it's at least removing an annoying message that doesn't even affect anything since the defaults are correct.
I don't think the version of GCC being used has the problem (it may be GCC 4.9 or so that does), but another thing I'm looking at is a bug where GCC memory use grows dramatically. In that case, removing '-pipe' from the compile options and trying just 'make' (aka, 'make -j1') might allow the compile to complete. This one shows up like a race condition so the symptoms pop up all over the place during compile and link -- it all depends on what is being done in parallel at that point in time. In this case, 'make -j2' may not be that big a deal, but I don't know how big the machine (or VM) is that's doing the compiling.
Here are the results with Dan's suggested fix from Comment 2 above
And no, it's not running out of memory — `make -j1` is not cure. Also -DWITH_BABELTRACE already been addressed and also wasn't the issue in the build failure.
I played with this a bit. Daniel seems to be right that we are missing cmake definitions for ppc64. However, adding that won't help as it looks like we have recently dropped the support for ppc in favor of ppc64le in some places. If you simply add the cmake support for ppc64, the code won't compile because the instructions for crc32c_ppc (the asm files) are written for ppc64le, not ppc64 (the code also requires altivec extension btw). I am currently running a scratch build that will build only a naive implementation (i.e. like it did on pre-power8 machines) of the crc32c_ppc module on ppc64. I'll keep you posted.
This should be fixed by the following command (my scratch build succeeded, running a regular build, now):
Eventually, it did require a bit more changes, specifically fixing the macros for the optimized crc32c code to build the optimized version on ppc64le only, build a naive implementation for other ppc platforms but not actually use it -- we have to use the sctp crc32 function instead on non-ppc64le platforms, at least for now.
The build completed succesfully: