On Saturday, 02 September, 2017 10:20 CEST, Jacco Ligthart <jacco at redsleeve.org> wrote: > > > On 09/02/2017 09:14 AM, Fabian Arrotin wrote: > > On 31/08/17 00:11, Jacco Ligthart wrote: > >>>> I also checked the other log > >>>> (https://armv7.dev.centos.org/rpmbuild/c71708-pass-1/19329-java-1.8.0-openjdk-1.8.0.131-11.b12.el7/armv7hl/build.log) > >>>> about resources.jar file missing, when it finds 1.7 and I exploded the > >>>> rpm through rpm2cpio to verify the content and yes, there is a > >>>> permission issue in the -headless package : > >>>> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.141-2.6.10.5.el7.arm/jre/lib/resources.jar > >>>> is 600 so probably not readable by mock itself (argh) > >>>> > >>>> Have now to investigate if the perm issue is due to that package build, > >>>> or if the .spec needs some changes to force better permissions. > >>>> > >>> So the issue with resources.jar is coming from an interim build that I'm > >>> missing, so have to rebuild it first (from the .spec) > >>> - Reset permissions of resources.jar to avoid it only being readable by > >>> root (PR1437). > >>> - Resolves: rhbz#1350042 (but that one is private so can't see what was > >>> changed) > >>> > >>> Seem linked to https://bugzilla.redhat.com/show_bug.cgi?id=1207129 though > >>> > >>> So I tried to rebuild older 1.7 pkg but it fails with "duplicate case > >>> value" . I then found this bug report, and Jacco is included in that bug > >>> report, the IT world is small after all :-) : > >>> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2942 > >>> > >>> I tried fixing 1.7 openjdk with the > >>> + ARM32JIT="false" \ > >>> patch for the make to ensure that it doesn't build arm32 JIT, but for > >>> strange reason it still tries to build it and fails again ... some other > >>> investigations required to rebuild older 1.7 from pre-7.4, then the one > >>> from 7.4 (with the resources.jar permission issue gone) and then 1.8 > >>> (hopefully) .. of course it happens on java, and on armhp, where each > >>> build needs *several* hours .... > >> I think the issue around ARM32JIT never got fixed, but by now ARM32JIT > >> is disabled by default. There should be no need to disable by hand. > >> > >> Jacco > > Hi Jacco, > > > > Now that I my java-1.7 issues are solved, I confirm that for 7.4.1708 I > > have exactly the same issue as you wrt GDB ( full log at > > http://armv7.dev.centos.org/rpmbuild/c71708-pass-1/19329-java-1.8.0-openjdk-1.8.0.131-11.b12.el7/) > > > > (gdb) (gdb) Breakpoint 1 (javaCalls.cpp:1) pending. > > (gdb) >>>(gdb) Starting program: > > /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.131-11.b12.el7.arm/openjdk/build/jdk8.build/images/j2sdk-image/bin/java > > -version > > No source file named javaCalls.cpp. > > [Thread debugging using libthread_db enabled] > > Using host libthread_db library "/lib/libthread_db.so.1". > > Missing separate debuginfos, use: debuginfo-install > > glibc-2.17-196.el7.armv7hl libgcc-4.8.5-16.el7.armv7hl > > zlib-1.2.7-17.el7.armv7hl > > (gdb) quit > > A debugging session is active. > > Inferior 1 [process 19549] will be killed. > > Quit anyway? (y or n) [answered Y; input not from terminal] > > warning: Probes-based dynamic linker interface failed. > > Reverting to original interface. > > Cannot access memory at address 0xc2400000 > > + grep JavaCallWrapper::JavaCallWrapper gdb.out > > RPM build errors: > > > > Wondering what can be done to fix this > > I don't know gdb enough to understand what it is they are doing here. Is > this a test? (we could just try and skip this) or does this change the > binaries in a meaningful way? > OK I had another look at this. I don't think the gdb section in the SPEC file adds anything to the package, it is just a test. I build java-1.8.0 without this section and it finishes normal. My gut feeling is that the java-1.8.0 binaries are OK, but that we found an error in gdb somehow. Not sure how to test/debug. Jacco