Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1091500
Summary: | jvm crashing on aarch64 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Peter Robinson <pbrobinson> |
Component: | java-1.7.0-openjdk | Assignee: | Andrew Haley <aph> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | urgent | ||
Version: | rawhide | CC: | adinn, ahughes, aph, dbhole, jerboaa, jvanek, omajid |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-06-05 21:29:50 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 922257 |
Description
Peter Robinson
2014-04-25 18:31:07 UTC
Assigning to Andrew to take a look. A likely very ignorant question but if we're going to be EOLing and removing java 1.7.x from Fedora in the F-21 timeframe shouldn't we be building 1.8.x with 1.8.x rather than 1.7.x to ensure no issues when it is removed? (In reply to Peter Robinson from comment #2) > A likely very ignorant question but if we're going to be EOLing and removing > java 1.7.x from Fedora in the F-21 timeframe shouldn't we be building 1.8.x > with 1.8.x rather than 1.7.x to ensure no issues when it is removed? It's not an ignorant question :) Building 1.8.x with 1.8.x has been on my todo list for a while, but I just haven't gotten around to it. (In reply to Omair Majid from comment #3) > (In reply to Peter Robinson from comment #2) > > A likely very ignorant question but if we're going to be EOLing and removing > > java 1.7.x from Fedora in the F-21 timeframe shouldn't we be building 1.8.x > > with 1.8.x rather than 1.7.x to ensure no issues when it is removed? > > It's not an ignorant question :) > > Building 1.8.x with 1.8.x has been on my todo list for a while, but I just > haven't gotten around to it. I actually tried to see if it would actually work with a scratch build and it appears to build at least on aarch64, no idea if it works or not. http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2287398 (In reply to Peter Robinson from comment #4) > I actually tried to see if it would actually work with a scratch build and > it appears to build at least on aarch64, no idea if it works or not. The last thing the build does is compile a tiny java program and run it. If the build works, it should not be completely broken. Any update? This is now severely impacting our ability to move aarch64 forwards. http://arm.koji.fedoraproject.org//work/tasks/1156/2301156/build.log This message suggests we have a 32-bit/64-bit problem here java_lib_arrays_wrap.c:641:13: note: expected 'jlong *' but argument is of type 'long long int *' That makes me suspect the installed java has not been built correctly -- specifically that the native libs have been built with the wrong gcc flags. We will will need to check the provenance of the installed java 7 version java-1.7.0-openjdk-1.7.0.60-2.5.0.16.pre02.fc21 in order to be sure Can you please tell me how to set up a local build environment for this? mock, maybe? Thanks. (In reply to Andrew Haley from comment #8) > Can you please tell me how to set up a local build environment for this? > mock, maybe? Thanks. Mock would be the same as per standard mock process http://fedoraproject.org/wiki/Using_Mock_to_test_package_builds config file would be fedora-rawhide-aarch64.cfg BTW, is this anything to do with GCC 4.9 ? Peter, what is the GCC version? (In reply to Andrew Haley from comment #12) > Peter, what is the GCC version? Last would have been built with gcc-4.9.0-1.fc21 I tried rebuilding the latest java-1.7.0-openjdk from mainline (java-1.7.0-openjdk-1.7.0.60-2.5.0.17.pre04.fc21) but it was FTBFS on mainline, and we had the previous one already http://koji.fedoraproject.org/koji/buildinfo?buildID=512375 If you are building OpenJDK on AArch64 with GCC 4.9, you need this patch: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965 (In reply to Andrew Haley from comment #14) > If you are building OpenJDK on AArch64 with GCC 4.9, you need this patch: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965 4.9.0-3 has that fix, just pushed a java-1.8.0-openjdk build against it now: http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2311420 Some updates: So untagging the OpenJDK7 build that was built with gcc 4.9 got us some improvements: OpenJDK7: The last mainline build (which built previously) fails: java-1.7.0-openjdk-1.7.0.60-2.5.0.16.pre02.fc21 http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2312189 OpenJDK8: I could rebuild a couple of OpenJDK8 releases: java-1.8.0-openjdk-1.8.0.5-2.b13.fc21 java-1.8.0-openjdk-1.8.0.5-3.b13.fc21 But java-1.8.0-openjdk-1.8.0.5-4.b13.fc21 fails: http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2312090 I think it might be getting the $JAVA_HOME/jre/lib/%{archinstall}/server/libjvm.so location wrong for aarch64. swig: build still crashing the jvm: http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2312092 This has been fixed by the GCC update. The SWIG build problem is not a bug in the JVM, but a bug in SWIG. We still have an issue building java-1.8.0-openjdk-1.8.0.5-4.b13.fc21 as documented above that hasn't been addressed. http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2319052 We're seeing the latest java-1.8.0-openjdk fail with the following error: + /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/images/j2sdk-image/bin/javac -d . /builddir/build/SOURCES/TestCryptoLevel.java + /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/images/j2sdk-image/bin/java TestCryptoLevel Running with the unlimited policy. + nm -aCl /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/images/j2sdk-image/jre/lib/aarch64/server/libjvm.so + grep javaCalls.cpp nm: '/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/images/j2sdk-image/jre/lib/aarch64/server/libjvm.so': No such file RPM build errors: Downloading a number of the previous java-1.8.0-openjdk aarch64 builds it seems none of them have server/libjvm.so and I've seen a few build java packages fail due to being unable to link to libjvm.so Comparing aarch64 I see that all other arches have server/libjvm.so but aarch64 has aarch64/client/libjvm.so so I'm wondering if this is as simple as a packaging or build options bug or some deeper problem that I'm missing. $ rpm -ql java-1.8.0-openjdk-headless-1.8.0.5-4.b13.fc21.x86_64 |grep libjvm.so /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.5.x86_64/jre/lib/amd64/server/libjvm.so $ rpm -qlp java-1.8.0-openjdk-headless-1.8.0.5-4.b13.fc21.i686.rpm |grep libjvm.so /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.5/jre/lib/i386/server/libjvm.so $ rpm -qlp java-1.8.0-openjdk-headless-1.8.0.5-4.b13.fc21.ppc64le.rpm |grep libjvm.so /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.5.ppc64le/jre/lib/ppc64le/server/libjvm.so $ rpm -qlp java-1.8.0-openjdk-headless-1.8.0.5-2.b13.fc21.ppc.rpm |grep libjvm.so /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.5/jre/lib/ppc/server/libjvm.so $ rpm -qlp java-1.8.0-openjdk-headless-1.8.0.5-2.b13.fc21.ppc64.rpm |grep libjvm.so /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.5.ppc64/jre/lib/ppc64/server/libjvm.so $ rpm -qlp java-1.8.0-openjdk-headless-1.8.0.5-4.b13.fc21.armv7hl.rpm |grep libjvm.so /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.5/jre/lib/arm/server/libjvm.so $ rpm -qlp java-1.8.0-openjdk-headless-1.8.0.5-3.b13.fc21.aarch64.rpm |grep libjvm.so /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.5.aarch64/jre/lib/aarch64/client/libjvm.so pl is an example of a java package not finding libjvm.so http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2322465 gmake[1]: Entering directory `/builddir/build/BUILD/pl-6.6.5/packages/jpl' gcc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -fno-strict-aliasing -Wall -fno-strict-aliasing -pthread -fPIC -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -I/builddir/build/BUILD/pl-6.6.5/src/../include -I'/usr/lib/jvm/java-1.8.0-openjdk.aarch64/include' -I'/usr/lib/jvm/java-1.8.0-openjdk.aarch64/include/linux' -DHAVE_CONFIG_H -D__SWI_PROLOG__ -c -o src/c/jpl.o src/c/jpl.c gcc -shared -rdynamic -Wl,--enable-new-dtags -pthread -Wl,-rpath=/usr/lib64/swipl-6.6.5/lib/aarch64-linux -L/builddir/build/BUILD/pl-6.6.5/src/../lib/aarch64-linux -o libjpl.so src/c/jpl.o -L/usr/java/packages/lib/aarch64 -L/lib -L/usr/lib -L/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.5.aarch64/jre/lib/aarch64 -L/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.5.aarch64/jre/lib/aarch64/server -ljava -lverify -ljvm -lswipl /usr/bin/ld: cannot find -ljvm collect2: error: ld returned 1 exit status gmake[1]: *** [libjpl.so] Error 1 gmake[1]: Leaving directory `/builddir/build/BUILD/pl-6.6.5/packages/jpl' make: *** [objects] Error 1 (In reply to Peter Robinson from comment #19) > + nm -aCl > /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/images/j2sdk- > image/jre/lib/aarch64/server/libjvm.so > + grep javaCalls.cpp > nm: > '/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/images/j2sdk- > image/jre/lib/aarch64/server/libjvm.so': No such file This is a recent change to the SPEC file which tries to assert that debuginfo is present in server/libjvm.so. I guess this test is wrong for aarch64. (In reply to Peter Robinson from comment #20) > pl is an example of a java package not finding libjvm.so > > http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2322465 > gcc -shared -rdynamic -Wl,--enable-new-dtags -pthread > -Wl,-rpath=/usr/lib64/swipl-6.6.5/lib/aarch64-linux > -L/builddir/build/BUILD/pl-6.6.5/src/../lib/aarch64-linux -o libjpl.so > src/c/jpl.o -L/usr/java/packages/lib/aarch64 -L/lib -L/usr/lib > -L/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.5.aarch64/jre/lib/aarch64 > -L/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.5.aarch64/jre/lib/aarch64/server > -ljava -lverify -ljvm -lswipl Thing is, there's no standard way in Fedora to say "give me a path suitable for using with -L for any java". pl makes this up itself in JavaConfig.java: 73 /* The java.library.path does not work since JDK 1.7. See 74 * <https://bugzilla.redhat.com/show_bug.cgi?id=740762>. */ 75 if (null == architecture || null == home || null == filesep) { 76 return null; 77 } 78 value = value + ":" + 79 home + filesep + "lib" + filesep + architecture + ":" + 80 home + filesep + "lib" + filesep + architecture + filesep + "server"; And what it computes is incorrect on aarch64. An additional issue is https://bugzilla.redhat.com/show_bug.cgi?id=449456#c5 (In reply to Omair Majid from comment #21) > (In reply to Peter Robinson from comment #19) > > + nm -aCl > > /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/images/j2sdk- > > image/jre/lib/aarch64/server/libjvm.so > > + grep javaCalls.cpp > > nm: > > '/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/images/j2sdk- > > image/jre/lib/aarch64/server/libjvm.so': No such file > > This is a recent change to the SPEC file which tries to assert that > debuginfo is present in server/libjvm.so. I guess this test is wrong for > aarch64. Should be fixed with: http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/commit/?id=f29294388ccc0dbacf0ae84d1b4045d119ccbd7b Could someone fix this patch up so it applies? A building 1.7.0 is the last blocker on this bug I think java-1.7.0-openjdk-1.7.0.60-2.5.0.20.pre04.fc21 http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2345004 Patch #4030 (PStack-808293-aarch64.patch): + /usr/bin/cat /builddir/build/SOURCES/PStack-808293-aarch64.patch + /usr/bin/patch -p0 --fuzz=0 patching file openjdk/hotspot/agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java + echo 'Patch #412 (add-final-location-rpaths.patch):' Patch #412 (add-final-location-rpaths.patch): + /usr/bin/cat /builddir/build/SOURCES/add-final-location-rpaths.patch + /usr/bin/patch -p0 --fuzz=0 patching file openjdk/jdk/make/common/Defs-linux.gmk Hunk #1 succeeded at 329 (offset -14 lines). patching file openjdk/jdk/make/common/Program.gmk Hunk #1 succeeded at 108 (offset -2 lines). Hunk #2 FAILED at 139. 1 out of 2 hunks FAILED -- saving rejects to file openjdk/jdk/make/common/Program.gmk.rej patching file openjdk/jdk/make/java/instrument/Makefile error: Bad exit status from /var/tmp/rpm-tmp.qOmjNh (%prep) RPM build errors: bogus date in %changelog: Thu Apr 22 2014 Jiri Vanek <jvanek> - 1.7.0.51-2.5.0.18.pre04.f21 Bad exit status from /var/tmp/rpm-tmp.qOmjNh (%prep) Child return code was: 1 EXCEPTION: Command failed. See logs for output. # ['bash', '--login', '-c', 'rpmbuild -bb --target aarch64 --nodeps builddir/build/SPECS/java-1.7.0-openjdk.spec'] Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py", line 70, in trace result = func(*args, **kw) File "/usr/lib/python2.7/site-packages/mockbuild/util.py", line 377, in do raise mockbuild.exception.Error, ("Command failed. See logs for output.\n # %s" % (command,), child.returncode) Error: Command failed. See logs for output. # ['bash', '--login', '-c', 'rpmbuild -bb --target aarch64 --nodeps builddir/build/SPECS/java-1.7.0-openjdk.spec'] LEAVE do --> EXCEPTION RAISED Hi Peter, why are we trying to build OpenJDK7 for F21? OpenJDK7 will not be part of F21. Is OpenJDK8 failing to build with the existing 7? (In reply to Peter Robinson from comment #24) > Could someone fix this patch up so it applies? A building 1.7.0 is the last > blocker on this bug I think I fixed it a few days ago: http://pkgs.fedoraproject.org/cgit/java-1.7.0-openjdk.git/commit/?id=b08e0a9f3b25b0dec03c75bbcd57f7c09409526e (In reply to Deepak Bhole from comment #25) > Hi Peter, why are we trying to build OpenJDK7 for F21? OpenJDK7 will not be > part of F21. Is OpenJDK8 failing to build with the existing 7? We are trying to build it because it's still part of mainline and it's still being used to build OpenJDK8. When OpenJDK8 is built with OpenJDK8 and v7 is blocked from mainline we will too then cease to care about v7 :) Speaking of which it looks like OpenJDK8 is broken again: java-1.8.0-openjdk-1.8.0.5-6.b13.fc21 http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2355291 + /usr/bin/touch /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc/_the.generated_nimbus >>> Generating beaninfo for javax.swing.AbstractButton... >>> Generating beaninfo for javax.swing.Box... >>> Generating beaninfo for javax.swing.JComponent... >>> Generating beaninfo for javax.swing.JApplet... >>> Generating beaninfo for javax.swing.JButton... >>> Generating beaninfo for javax.swing.JCheckBox... >>> Generating beaninfo for javax.swing.JCheckBoxMenuItem... >>> Generating beaninfo for javax.swing.JComboBox... >>> Generating beaninfo for javax.swing.JColorChooser... >>> Generating beaninfo for javax.swing.JDesktopPane... >>> Generating beaninfo for javax.swing.JDialog... >>> Generating beaninfo for javax.swing.JEditorPane... >>> Generating beaninfo for javax.swing.JFileChooser... >>> Generating beaninfo for javax.swing.JFrame... >>> Generating beaninfo for javax.swing.JFormattedTextField... >>> Generating beaninfo for javax.swing.JInternalFrame... >>> Generating beaninfo for javax.swing.JLabel... >>> Generating beaninfo for javax.swing.JLayeredPane... >>> Generating beaninfo for javax.swing.JList... >>> Generating beaninfo for javax.swing.JMenu... >>> Generating beaninfo for javax.swing.JMenuBar... >>> Generating beaninfo for javax.swing.JMenuItem... >>> Generating beaninfo for javax.swing.JOptionPane... >>> Generating beaninfo for javax.swing.JPanel... >>> Generating beaninfo for javax.swing.JPasswordField... >>> Generating beaninfo for javax.swing.JPopupMenu... >>> Generating beaninfo for javax.swing.JProgressBar... >>> Generating beaninfo for javax.swing.JRadioButton... >>> Generating beaninfo for javax.swing.JRadioButtonMenuItem... >>> Generating beaninfo for javax.swing.JScrollBar... >>> Generating beaninfo for javax.swing.JScrollPane... >>> Generating beaninfo for javax.swing.JSeparator... >>> Generating beaninfo for javax.swing.JSlider... >>> Generating beaninfo for javax.swing.JSplitPane... >>> Generating beaninfo for javax.swing.JSpinner... >>> Generating beaninfo for javax.swing.JTabbedPane... >>> Generating beaninfo for javax.swing.JTable... >>> Generating beaninfo for javax.swing.JTextArea... >>> Generating beaninfo for javax.swing.JTextField... >>> Generating beaninfo for javax.swing.JTextPane... >>> Generating beaninfo for javax.swing.JToggleButton... >>> Generating beaninfo for javax.swing.JToolBar... >>> Generating beaninfo for javax.swing.JTree... >>> Generating beaninfo for javax.swing.JWindow... >>> Generating beaninfo for javax.swing.text.JTextComponent... # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x000003ff7d07d53c, pid=7213, tid=4395842269664 # # JRE version: OpenJDK Runtime Environment (7.0_60-b04) (build 1.7.0_60-aarch64-831-b04) # Java VM: OpenJDK 64-Bit Server VM (25.0-b69 mixed mode linux-aarch64 compressed oops) # Problematic frame: # V [libjvm.so+0x48d53c] AsyncGetCallTrace+0x703b0 # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/make/hs_err_pid7213.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/common/bin/shell-tracer.sh: line 47: 7213 Aborted "$OLD_SHELL" -x "$@" gmake[2]: *** [/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_no_srczip/_the.generated_beaninfo] Error 134 gmake[2]: *** Waiting for unfinished jobs.... # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x000003ffa4e3d53c, pid=7204, tid=4396510999008 # # JRE version: OpenJDK Runtime Environment (7.0_60-b04) (build 1.7.0_60-aarch64-831-b04) # Java VM: OpenJDK 64-Bit Server VM (25.0-b69 mixed mode linux-aarch64 compressed oops) # Problematic frame: # V [libjvm.so+0x48d53c] AsyncGetCallTrace+0x703b0 # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/make/hs_err_pid7204.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/common/bin/shell-tracer.sh: line 47: 7204 Aborted "$OLD_SHELL" -x "$@" gmake[2]: *** [/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc/sun/util/cldr/CLDRLocaleDataMetaInfo.java] Error 134 gmake[2]: Leaving directory `/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/make' gmake[1]: *** [gensrc-only] Error 2 gmake[1]: Leaving directory `/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/make' make: *** [jdk-only] Error 2 (In reply to Peter Robinson from comment #28) > # JRE version: OpenJDK Runtime Environment (7.0_60-b04) (build > 1.7.0_60-aarch64-831-b04) > # Java VM: OpenJDK 64-Bit Server VM (25.0-b69 mixed mode linux-aarch64 > compressed oops) It's the 7 JRE that segfaults. We're still having build failures, any update to when we might get a fix? http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2358169 I am totally confused about this. These seem to be a long list of unrelated bugs but they all get assigned the same bug ID. Has OpenJDK 8 ever built for you? When was OpenJDK 7 built? Was it built with the broken GCC 4.8? You said it built, now you say it's broken again. What has changed? (In reply to Andrew Haley from comment #31) > I am totally confused about this. These seem to be a long list of unrelated > bugs but they all get assigned the same bug ID. They are all the same to me. IE building of java is broken. At the moment it uses OpenJDK7 (what this bug is about) to build OpenJDK8. I can open a new bug with every separate failure I really could care less either way. I tend to use the same one as it provides history and consistency and basically we have the same problem I had when I first opened this bug in that OpenJDK8 doesn't currently build. > Has OpenJDK 8 ever built for you? Yes. As can be easily seen here if you bothered to check (F-21 builds are aarch64) http://arm.koji.fedoraproject.org/koji/packageinfo?packageID=15559 > When was OpenJDK 7 built? Was it built with the broken GCC 4.8? No, it was built with gcc-4.9.0-5.fc21 (yes, that has the gcc bug fix for aarch64 that was previously discussed) which also happens to be the same NVR used for mainline x86/armv7 http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=197002 (In reply to Andrew Haley from comment #32) > You said it built, now you say it's broken again. What has changed? Probably the newer OpenJDK7 that was built in mainline but I'm not a java expert so your likely better to answer that :-) Ultimately if there's newer deps in mainline we build them and then the newer OpenJDK will build against those new deps. It's called rawhide :-) Ok, this bug is completely unrelated to the earlier one. It's nothing to do with the GCC miscompilation. The OpenJDK 7 that is being used to build OpenJDK 8 is rather old and needs to be refreshed. Unfortunately, we have a bootstrapping problem: it can't build itself. So, we're going to need some new packages built. I'm doing a scratch build of OpenJDK 7 and I'll test it locally in mock. (In reply to Andrew Haley from comment #35) > Ok, this bug is completely unrelated to the earlier one. It's nothing to do > with the GCC miscompilation. The OpenJDK 7 that is being used to build > OpenJDK 8 is rather old and needs to be refreshed. Unfortunately, we have a > bootstrapping problem: it can't build itself. Isn't OpenJDK7 due to be retired before F-21 is out? If that is the case wouldn't it be better to do the work to bootstrap OpenJDK8 to build itself (a scratch build I did changing the deps in the spec earlier appeared to compile, but not tested). Ultimately we need to do what ever mainline does. (In reply to Peter Robinson from comment #36) > (In reply to Andrew Haley from comment #35) > > Ok, this bug is completely unrelated to the earlier one. It's nothing to do > > with the GCC miscompilation. The OpenJDK 7 that is being used to build > > OpenJDK 8 is rather old and needs to be refreshed. Unfortunately, we have a > > bootstrapping problem: it can't build itself. > > Isn't OpenJDK7 due to be retired before F-21 is out? If that is the case > wouldn't it be better to do the work to bootstrap OpenJDK8 to build itself > (a scratch build I did changing the deps in the spec earlier appeared to > compile, but not tested). Ultimately we need to do what ever mainline does. Well, sure, but this requires a change to the RPM used on all the other targets, and that'll need testing. If it works OK, sure. I have placed RPMs which can be used to bootstrap OpenJDK 7 on AARch64 at http://aph.fedorapeople.org/java-1.7.0-openjdk1.7.0.60-2.5.0.22.pre04.fc19.aarch64.tar Omair has created new RPMs with the corrected sources; I don't know if he has pushed them to Koji. It would be good to get OpenJDK 7 building again. I'm quite happy that we should no longer require OpenJDK 8 in Fedora to build with OpenJDK 7. It's time. That URL was corrupted. http://aph.fedorapeople.org/java-1.7.0-openjdk-1.7.0.60-2.5.0.22.pre04.fc19.aarch64.tar (In reply to Andrew Haley from comment #38) > Omair has created new RPMs with the corrected sources; I don't know if he > has pushed them to Koji. Not yet, but since they require 7 to build, they will still be broken. > It would be good to get OpenJDK 7 building again. Peter, can we untag aarch64-port-based OpenJDK 7 builds from arm-koji? Andrew Haley tells me that it's safest to use the zero-port (a really, really old RPM build of java-1.7.0-openjdk) to bootstrap OpenJDK 7 again. > I'm quite happy that we should no longer require OpenJDK 8 in Fedora to > build with OpenJDK 7. It's time. This isn't done yet; I will be pushing this as soon as I can, though. Possibly today. This is the last RPM built without the hotspot aarch64-port: http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=185526 I can untag back as far as you like WRT OpenJDK7 builds. Basically I just need a list of the NVRs to untag. So if I read the above right we need to do: 1) untag builds with issues (presumably I should reset them so we don't accidentally pull/tag them again) 2) rebuild with a special rpm? 3) build a koji NVR? Is that correct? (In reply to Peter Robinson from comment #42) > I can untag back as far as you like WRT OpenJDK7 builds. Basically I just > need a list of the NVRs to untag. Thanks! > 1) untag builds with issues (presumably I should reset them so we don't > accidentally pull/tag them again) This version should work well: java-1.7.0-openjdk-1.7.0.60-2.4.4.2.fc21 All the newer f21 versions listed on http://arm.koji.fedoraproject.org/koji/packageinfo?packageID=12078 need to go: java-1.7.0-openjdk-1.7.0.60-2.5.0.21.pre04.fc21 java-1.7.0-openjdk-1.7.0.60-2.5.0.16.pre02.fc21 java-1.7.0-openjdk-1.7.0.60-2.5.0.20.pre04.fc21 java-1.7.0-openjdk-1.7.0.60-2.5.0.14.pre02.fc21 java-1.7.0-openjdk-1.7.0.60-2.5.0.13.pre02.fc21 java-1.7.0-openjdk-1.7.0.60-2.5.0.12.pre02.fc21 java-1.7.0-openjdk-1.7.0.60-2.5.0.4.pre02.fc21 > 2) rebuild with a special rpm? No. The old OpenJDK 7 rpm should be okay, but slow. > 3) build a koji NVR? Yes. I am going to push an update to the java-1.7.0-openjdk package. I will make a note here when I do. Please build that in koji using the known-to-work OpenJDK 7. Thanks. OK, once I get the NVR for the new one I'll deal with the rest above (In reply to Peter Robinson from comment #44) > OK, once I get the NVR for the new one I'll deal with the rest above java-1.7.0-openjdk-1.7.0.60-2.5.0.22.pre04.fc21 This is the koji build: http://koji.fedoraproject.org/koji/buildinfo?buildID=520972 (In reply to Andrew Haley from comment #38) > I'm quite happy that we should no longer require OpenJDK 8 in Fedora to > build with OpenJDK 7. It's time. Fixed with: http://koji.fedoraproject.org/koji/buildinfo?buildID=520939 thanks, in process, will update once (hopefully) complete All seems to be good now, thank you all for your assistance :) |