Bug 1474774

see build log at 

https://koji.fedoraproject.org/koji/taskinfo?taskID=20683233

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)
+  if(HAVE_POWER8)
+    message(STATUS " HAVE_POWER8 yes")
+  endif()

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 --

CMake Warning:
  Manually-specified variables were not used by the project:
    WTIH_BABELTRACE

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

   https://kojipkgs.fedoraproject.org//work/tasks/6524/20946524/build.log

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):

http://pkgs.fedoraproject.org/cgit/rpms/ceph.git/commit/?id=13a18359e9f68423b1b1f0c62b9fe3f75d4e0094

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:

https://koji.fedoraproject.org/koji/taskinfo?taskID=20961346