Description of problem: java-1.7.0-openjdk-1.7.0.3-2.2.1.fc17.7 fails to build on ppc with the following build error: Compiling /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/utilities/decoder.cpp rm -f decoder.o g++ -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO -DTARGET_ARCH_NYI_6939861=1 -DPPC -DZERO_LIBARCH=\"ppc\" -DPRODUCT -I. -I/builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/prims -I/builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm -I/builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/precompiled -I/builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/cpu/zero/vm -I/builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/os_cpu/linux_zero/vm -I/builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/os/linux/vm -I/builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"23.0-b21\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"mockbuild\"" -DHOTSPOT_LIB_ARCH=\"ppc\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_zero -DTARGET_ARCH_MODEL_zero -DTARGET_OS_ARCH_linux_zero -DTARGET_OS_ARCH_MODEL_linux_zero -DTARGET_COMPILER_gcc -I/usr/lib/libffi-3.0.10/include -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -pipe -g -O3 -fno-strict-aliasing -gstabs -DINCLUDE_TRACE -Werror -Wpointer-arith -Wsign-compare -c -MMD -MP -MF ../generated/dependencies/decoder.o.d -o decoder.o /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/utilities/decoder.cpp make[6]: *** [cppInterpreter_zero.o] Error 1 Full build logs are available from https://ppc.koji.fedoraproject.org/koji/getfile?taskID=602682&name=build.log The last version of java-1.7.0-openjdk to build correctly is java-1.7.0-openjdk-1.7.0.3-2.1.fc17.7
from Chris' reply to my email: ... This looks like we are building in a later hotspot jvm than 22 (23? maybe from icedtea7-forest-2.2?). I don't think zero builds on anything other than icedtea7-forest-2.1 at the moment due to significant structure changes after hsx 22 in the invoke dynamic code [Ricochet frame dependency].
This is going to be problematic -- we don't want to keep all of Fedora at a lower OpenJDK7 version due to HS23 issues. I think we may need a separate branch for s390/arm that uses the older version of OpenJDK7 till this is resolved. Chris, how long do you think will it take to add at least basic HS23 support?
Copied the wrong snippet from the build log. Should have included: /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp: In static member function 'static void CppInterpreter::process_method_handle(oop, Thread*)': /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp:817:7: error: 'get_ek_bound_mh_info' is not a member of 'MethodHandles' /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp:965:7: error: 'get_ek_adapter_opt_swap_rot_info' is not a member of 'MethodHandles'
*** Bug 837415 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > I think we may need a separate > branch for s390/arm that uses the older version of OpenJDK7 till this is > resolved. Would that be something you'd be able to %ifarch in the package? Secondary architectures (and it seems like all of us (arm, ppc, & s390) are hitting this) aren't allowed to fork a completely separate version of a package that's provided in fedora
In order to ifarch it, we would have to vary the sources used -- essentially we would be bundling two different versions into the same SRPM if we were to ifarch it and that would lead to other issues as different versions may have different files and what not.
(In reply to comment #5) > (In reply to comment #2) > > I think we may need a separate > > branch for s390/arm that uses the older version of OpenJDK7 till this is > > resolved. > > Would that be something you'd be able to %ifarch in the package? Secondary > architectures (and it seems like all of us (arm, ppc, & s390) are hitting > this) aren't allowed to fork a completely separate version of a package > that's provided in fedora Not sure what the effort would be to support/review secondary arches as part of the upstream development so we don't get into this situation. It's not hard to throw scratch builds at the various architectures koji wise and it might be possible to setup something closer to mainline than that
Okay, so it seems that we may have no choice but to fork the spec file for arm/s390/ppc. We don't expect HS23 support to land until September/October. We do not want to keep the rest of Fedora at a lower level till then. If there are no objections to forking, we can look into branch creation by Friday/Monday. Does the branch need to have a specific name so that koji will pick it?
(In reply to comment #8) > Okay, so it seems that we may have no choice but to fork the spec file for > arm/s390/ppc. > > We don't expect HS23 support to land until September/October. We do not want > to keep the rest of Fedora at a lower level till then. > > If there are no objections to forking, we can look into branch creation by > Friday/Monday. > > Does the branch need to have a specific name so that koji will pick it? This will have to go to FESCo for approval, there is no means of handling it koji as it's against Fedora policy. How is it that other arches were completely ignored in this process and how is the underlying code so different that it doesn't compile of arches other than x86?
(In reply to comment #9) > How is it that other arches were completely ignored in this process and how > is the underlying code so different that it doesn't compile of arches other > than x86? 1) Because Zero is a hl (c++) interpreter that is not maintained by Oracle, and nor most of the rest of the OpenJDK developers. 2) Because invoke dynamic is a major alteration of the JVM still evolving to support lambda and get creditable performance, ergo the development of the machine oriented Ricochet frame mechanism in hsx 22-24 time frame that is directly linked to the template interpreter hs compiler environment by machine code for each of the supported archs (x86,x86_64,sparc,sparcv9), requiring a deeper code change in Zero. 3) Because jdk7 has a validation suite that includes verifying some of the above invoke dynamic capabilities. Cheers. PS You are welcome to examine the source and present patches to make zero work.
java-1.7.0-openjdk-1.7.0.5-2.2.1.fc18.9 builds on ARM, I've not yet testing it further as yet
Fixed as of java-1.7.0-openjdk-1.7.0.5-2.2.1.fc17.9
Deepak, this hasn't been submitted as an update to F17 yet.
Hi Peter, do you mean they haven't been submitted via Bodhi? I did not do so because there is no code difference for primary architectures. Is Bodhi update creation required for secondary as well? The builds are done in Koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=329654 http://koji.fedoraproject.org/koji/buildinfo?buildID=329645
(In reply to comment #14) > Hi Peter, do you mean they haven't been submitted via Bodhi? > > I did not do so because there is no code difference for primary > architectures. Is Bodhi update creation required for secondary as well? You need to because secondary policy states that we only ship packages shipped in Fedora mainline, if it's not tagged into the release it's not shipped as an update
Ah, sorry I was not aware. Is this needed for F16 as well or will F17 and rawhide suffice?
(In reply to comment #16) > Ah, sorry I was not aware. Is this needed for F16 as well or will F17 and > rawhide suffice? F17 will suffice for ARM, rawhide is automatically pushed so it's already there. PPC will need to comment for their use case but F17 will be a good start.
java-1.7.0-openjdk-1.7.0.5-2.2.1.fc17.9 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/java-1.7.0-openjdk-1.7.0.5-2.2.1.fc17.9
Thanks! F17 update submitted: https://admin.fedoraproject.org/updates/java-1.7.0-openjdk-1.7.0.5-2.2.1.fc17.9
Package java-1.7.0-openjdk-1.7.0.5-2.2.1.fc17.9: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing java-1.7.0-openjdk-1.7.0.5-2.2.1.fc17.9' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-11054/java-1.7.0-openjdk-1.7.0.5-2.2.1.fc17.9 then log in and leave karma (feedback).
java-1.7.0-openjdk-1.7.0.5-2.2.1.fc17.9 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.