Description of problem: The file list java-1.8.0-openjdk.files doesn't get created on ppc64le: Processing files: java-1.8.0-openjdk-1.8.0.20-1.b26.fc21.ppc64le error: Could not open %files file /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.20-1.b26.fc21.ppc64le/java-1.8.0-openjdk.files: No such file or directory RPM build errors: Could not open %files file /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.20-1.b26.fc21.ppc64le/java-1.8.0-openjdk.files: No such file or directory Child return code was: 1 Version-Release number of selected component (if applicable): java-1.8.0-openjdk-1.8.0.20-1.b26.fc21. How reproducible: always Steps to Reproduce: 1. ppc-koji build --scratch f21 java-1.8.0-openjdk-1.8.0.20-1.b26.fc21.src.rpm 2. 3. Actual results: http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2068809 Expected results: Additional info:
ok. the filtering is wrong, there is nowhere xYES in log The regex is expecting something like .../lib/ppc64le/... - {archinstall} but on the the build is done into normal .../lib/ppc64/.. I think that best solution is to get rid of this ppc64le archinstall value. It seems that it is not used, and notrmal ppc is used instead.
One more note, if archinstall is broken like this, then not only filelist is corrupted. fgrep archinstall form specfile - audio, jsa, systemtap.... everything points to ppc64le....
Created attachment 934236 [details] patch for spec file to add ppc64le as a jit arch and a variant of ppc64 The attached patch (sort of) tries to address the problem and makes the ppc64le build a jit build (rather than zero). But building this leads to weird errors, like: /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.20-2.b26.fc21.ppc64le/jdk8/hotspot/src/cpu/ppc/vm/interp_masm_ppc_64.cpp:122:29: error: 'FunctionDescriptor' was not declared in this scope call_c(CAST_FROM_FN_PTR(FunctionDescriptor*, FunctionDescriptor is defined in an #if !defined(ABI_ELFv2) block (in hotspot/src/cpu/ppc/vm/assembler_ppc.hpp) and the makfile (hotspot/make/linux/makefiles/ppc64.make) says '# Little endian machine uses ELFv2 ABI' I am a little confused about the upstream build status of ppc64le now.
There is small error in your patch. To jit only ppc64le should be added. Not whole ppc swarm. Otherwise yes:(( I will push this change to rhel 7 and f21+f22
(In reply to jiri vanek from comment #4) > To jit only ppc64le should be added. Not > whole ppc swarm. Are you sure about that? I figured the %{power64} macro indicates ppc64 and its variants. Upstream JIT exists for both ppc64be and ppc64le AFAIK. Anyway, turns out the missing bit was the interpreter.. A scratch build [1] completed with the `--with-jvm-interpreter=cpp` argument suggested at [2]. Apparently only the cpp interpreter is supported on ppc64le. Please note that the scratch build built on ppc64(be) and ppc64le, with my original patch - the JIT is enabled for both. I have pushed the ccp-interpreter change. [1] http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2078350 [2] http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2014-July/002065.html
The original patch is correct; the only PPC platforms not supported by the PPC JIT is ppc32 and some early (<power5) versions of ppc64. ppc64be is actually better supported than ppc64le and the original reason we split them in 7 was so that Zero was still used for ppc64le, which didn't have support from the PPC port back then. The cpp interpreter is used by the JIT on both architectures, I believe. What I don't understand is why this isn't automatically turned on for this architecture. In merging with 7, I fixed it to do this: http://icedtea.classpath.org/hg/icedtea7-forest/hotspot/rev/43b9c3182bd1b0
s/is ppc32/are ppc32/ Serves me right for rewording.