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? Jacco