I see 2 problems with recent mp on non-x86 arches in general

1. thirdparty/benchmark/src/cycleclock.h requiring a native implementation, which can be easily fixed with something like

diff -up mp-3.1.0/thirdparty/benchmark/src/cycleclock.h.secarch mp-3.1.0/thirdparty/benchmark/src/cycleclock.h
--- mp-3.1.0/thirdparty/benchmark/src/cycleclock.h.secarch      2016-05-05 11:36:28.000000000 +0200
+++ mp-3.1.0/thirdparty/benchmark/src/cycleclock.h      2016-05-05 11:45:38.000000000 +0200
@@ -136,7 +136,9 @@ inline BENCHMARK_ALWAYS_INLINE int64_t N
 // The soft failover to a generic implementation is automatic only for ARM.
 // For other platforms the developer is expected to make an attempt to create
 // a fast implementation and use generic version if nothing better is available.
-#error You need to define CycleTimer for your OS and CPU
+  struct timeval tv;
+  gettimeofday(&tv, nullptr);
+  return static_cast<int64_t>(tv.tv_sec) * 1000000 + tv.tv_usec;
 #endif
 }
 }  // end namespace cycleclock

2. JNI detection when built with "jacop"

in solvers/jacop/CMakeLists.txt see 
  ...
  if (CMAKE_SIZEOF_VOID_P EQUAL 4)
    # Set CMAKE_SYSTEM_PROCESSOR to make sure FindJNI finds the correct
    # AWT and JVM libraries.
    set(CMAKE_SYSTEM_PROCESSOR i586)
  endif ()

which is simply wrong (and I suppose the reason for %ifnarch %{arm} aarch64 in the spec file)

Version-Release number of selected component (if applicable):
mp-3.1.0-1.fc25