[Arm-dev] java-1.8.0 not building on armv5

Fabian Arrotin arrfab at centos.org
Wed Aug 30 08:14:49 UTC 2017


On 29/08/17 19:50, Jacco Ligthart wrote:
> On 08/29/17 10:19, Fabian Arrotin wrote:
>> On 27/08/17 20:13, Jacco Ligthart wrote:
>>> Hi Fabian,
>>>
>>> I fail to build java-1.8.0-openjdk on armv5.
>>>
>>> I get errors regarding gdb:
>>>
>>> + gdb -q
>>> /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.141-2.b16.el7.arm/openjdk/build/jdk8.build/images/j2sdk-image/bin/java
>>> + tee gdb.out
>>> Reading symbols from
>>> /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.141-2.b16.el7.arm/openjdk/build/jdk8.build/images/j2sdk-image/bin/java...done.
>>> (gdb) Signal        Stop        Print   Pass to program Description
>>> SIGSEGV       No        No      Yes             Segmentation fault
>>> (gdb) Signal        Stop        Print   Pass to program Description
>>> SIGILL        No        No      Yes             Illegal instruction
>>> (gdb) (gdb) Breakpoint 1 (javaCalls.cpp:1) pending.
>>> (gdb) >>>(gdb) Starting program:
>>> /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.141-2.b16.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".
>>> warning: Probes-based dynamic linker interface failed.
>>> Reverting to original interface.
>>> Cannot access memory at address 0xc2400000
>>> Missing separate debuginfos, use: debuginfo-install
>>> glibc-2.17-157.el7.4.redsleeve.armv5tel libgcc-4.8.5-11.el7.armv5tel
>>> zlib-1.2.7-17.el7.armv5tel
>>> (gdb) quit
>>> A debugging session is active.
>>>
>>>
>>> This is all related to a new section about gdb in the SPEC-file:
>>>
>>> # Make sure gdb can do a backtrace based on line numbers on libjvm.so
>>> gdb -q "$JAVA_HOME/bin/java" <<EOF | tee gdb.out
>>> handle SIGSEGV pass nostop noprint
>>> handle SIGILL pass nostop noprint
>>> set breakpoint pending on
>>> break javaCalls.cpp:1
>>> commands 1
>>> backtrace
>>> quit
>>> end
>>> run -version
>>> EOF
>>> grep 'JavaCallWrapper::JavaCallWrapper' gdb.out
>>>
>>>
>>> Now my question, does this build on armv7 ?
>>>
>>> Jacco
>> Hi Jacco,
>>
>> I'm just back from "offline/holidays" mode but I saw the issue before
>> leaving, and have still to find the fix.
>>
>> What is interesting is that it seems a different error message on armv7
>> (from
>> 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)
>> :
>>
>> Caused by: java.io.FileNotFoundException:
>> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.141-2.6.10.5.el7.arm/jre/lib/resources.jar
>> (Permission denied)
>>
>> Don't know why it grabbed 1.7 in the first place in the mock chroot
>> (DEBUG util.py:417:   -->
>> 1:java-1.7.0-openjdk-devel-1.7.0.141-2.6.10.5.el7.armv7hl) , so maybe
>> some different mock config file is needed to enforce only fetching 1.8 ?
>> I'll give it a try later
> Strange that you have a different error.
> 
> I do know why it grabs 1.7. The Spec file states:
> # Use OpenJDK 7 where available (on RHEL) to avoid
> # having to use the rhel-7.x-java-unsafe-candidate hack
> %if 0%{?rhel}
> BuildRequires: java-1.7.0-openjdk-devel
> %else
> BuildRequires: java-1.8.0-openjdk-devel
> %endif
> 
> Apparently we qualify as "rhel" here.
> 
> Jacco

Hi Jacco,

So two things :

I tried to build it against 7.3.1611+updates and then I confirm what
you're seeing with gdb
(https://armv7.dev.centos.org/rpmbuild/c71611-updates-1/19786-java-1.8.0-openjdk-1.8.0.131-11.b12.el7/armv7hl/build.log)
:

+ gdb -q
/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.131-11.b12.el7.arm/openjdk/build/jdk8.build/imag
es/j2sdk-image/bin/java
Reading symbols from
/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.131-11.b12.el7.arm/openjdk/build/jdk
8.build/images/j2sdk-image/bin/java...done.
(gdb) Signal        Stop        Print   Pass to program Description
SIGSEGV       No        No      Yes             Segmentation fault
(gdb) Signal        Stop        Print   Pass to program Description
SIGILL        No        No      Yes             Illegal instruction
(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-157.el7.5.armv7hl libgcc-4.8.5-11.el7.armv7hl
zlib-1.2.7-17.el7.armv7hl
(gdb) warning: Probes-based dynamic linker interface failed.
Reverting to original interface.
Cannot access memory at address 0xc2400000
quit
A debugging session is active.
        Inferior 1 [process 4802] will be killed.
Quit anyway? (y or n) [answered Y; input not from terminal]
+ grep JavaCallWrapper::JavaCallWrapper gdb.out
RPM build errors:
error: Bad exit status from /var/tmp/rpm-tmp.LcfCwP (%check)
    Bad exit status from /var/tmp/rpm-tmp.LcfCwP (%check)
Child return code was: 1
EXCEPTION: [Error()]

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.

-- 
-- 
Fabian Arrotin
The CentOS Project | http://www.centos.org
gpg key: 56BEC54E | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/arm-dev/attachments/20170830/2cfbc010/attachment.sig>


More information about the Arm-dev mailing list