openjdk team mailing list archive

[Tiago Stürmer Daitx <1438575@xxxxxxxxxxxxxxxxxx>]

Hi Luciano,

My apologies, while I'm subscribed to this bug for some reason I missed
the message from your last comment. To answer your question: besides re-
compiling openjdk 7 on their own, there is not much a user can do (* see
bellow for a hack-ish way)

This issue has been fixed in IcedTea 2.6+ which is only available for
Wily.

-> 2.6.1 (Wily)
$ java -XshowSettings -version 2>&1 | grep -e IcedTea -e os.arch -e sun.boot.library.path
    os.arch = ppc64le
    sun.boot.library.path = /usr/lib/jvm/java-7-openjdk-ppc64el/jre/lib/ppc64le
OpenJDK Runtime Environment (IcedTea 2.6.1) (7u85-2.6.1-5)

-> 2.5.6 (Vivid, Trusty)
$ java -XshowSettings -version 2>&1 | grep -e IcedTea -e os.arch -e sun.boot.library.path
    os.arch = ppc64
    sun.boot.library.path = /usr/lib/jvm/java-7-openjdk-ppc64el/jre/lib/ppc64
OpenJDK Runtime Environment (IcedTea 2.5.6) (7u79-2.5.6-0ubuntu1.15.04.1)


I will check if we can update Vivid and Trusty to 2.6.x in the upcoming IcedTea 2.6.2 release that I'm working on, otherwise I will provide an SRU with the patch to fix this.


** Ugly hack **
Remember: use at your own risk, don't try it at home, keep the kids away, yada yada. ;-)

It is possible to get os.arch to return "ppc64le" by modifying the
libjava.so file in jre/lib/ppc64

The following information is valid for Vivid, I haven't checked but Trusty offsets might be different. 
Using a hex editor (eg. hexedit), go to position 0x2B938, where it should show in ASCII "little..ppc64...GNOME_DESKTOP_SESSION_ID" and modify the 'ppc64' entry to 'ppc64le' (overwriting 2 null bytes).

$ cmp -lb libjava.so.orig libjava.so
178494   0 ^@   154 l
178495   0 ^@   145 e

$ java -XshowSettings -version 2>&1 | grep -e IcedTea -e os.arch -e sun.boot.library.path
    os.arch = ppc64le
    sun.boot.library.path = /usr/lib/jvm/java-7-openjdk-ppc64el/jre/lib/ppc64
OpenJDK Runtime Environment (IcedTea 2.5.6) (7u79-2.5.6-0ubuntu1.15.04.1)

With that, programs that depend on os.arch might work as expected (I
haven't test anything besides the -XshowSettings test above).

Depending on how the program behaves, you might also need to link the 'ppc64' lib arch dir to 'ppc64le', eg:
# cd /usr/lib/jvm/java-7-openjdk-ppc64el/jre/lib
# ln -s ppc64 ppc64le

If you do test this, let me know the results and what programs you
tested it with. I'm a bit curious on how well it might work. =)

-- 
You received this bug notification because you are a member of OpenJDK,
which is subscribed to openjdk-7 in Ubuntu.
https://bugs.launchpad.net/bugs/1438575

Title:
  OpenJdk 7 and OpenJdk 8 miss-report the os.arch field and cause java
  apps to crash.

Status in openjdk-7 package in Ubuntu:
  Fix Released
Status in openjdk-8 package in Ubuntu:
  New

Bug description:
  Problem Description
  =======================================
  OpenJdk 7 and OpenJdk 8 miss report the os.arch field and cause java apps to crash.

  When we run under OpenJDK on a ubuntu ppc64el system the os.arch
  system properites gets reported as ppc64.

  This causes multiple java libraries to load the wrong native
  architecture modules as it thinks this is a big endian machine, rather
  than a ppc64le machine.

  ---uname output---
  Linux tulgpu002 3.16.0-30-generic #40-Ubuntu SMP Mon Jan 12 22:07:11 UTC 2015 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = 8247-42L 

  Steps to Reproduce
  ===================================================
  make sure an openjdk is installed.
  sudo apt-get install openjdk-7-jdk

  Create a  very simple java properties dumper.

  cat >sysprop.java <<EOF
  class sysprop{
    public static void main(String[] args){
      System.getProperties().list(System.out);
     }
  }
  EOF

  and run it and look for the os.arch output.

  
  javac sysprop.java

  ralphbel@tulgpu002:~/java$ java sysprop |  grep arch
  os.arch=ppc64
  sun.arch.data.model=64

  == Comment: #2 - Ralph E. Bellofatto <ralphbel@xxxxxxxxxx> - 2015-03-17 05:39:29 ==
  Acutally this is ubuntu 14.10.

  ralphbel@tulgpu002:~/java$ lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:    Ubuntu 14.10
  Release:        14.10
  Codename:       utopic

  I suspect this problem also exists on the ubuntu 14.04 releases
  although we have not tried that yet...

  == Comment: #3 - Ralph E. Bellofatto <ralphbel@xxxxxxxxxx> - 2015-03-17 05:51:04 ==
  more information on the package we are using:

  ralphbel@tulgpu002:~/jnr-ffi$ apt-cache policy openjdk-7-jdk
  openjdk-7-jdk:
    Installed: 7u75-2.5.4-1~utopic1
  and
  ralphbel@tulgpu002:~/jnr-ffi$ apt-cache policy openjdk-8-jdk
  openjdk-8-jdk:
    Installed: 8u40~b09-1

  == Comment: #4 - Ralph E. Bellofatto <ralphbel@xxxxxxxxxx> - 2015-03-18 15:04:51 ==
  This is an interesting comment in the openJDK bugs database:

  ****************************
  https://bugs.openjdk.java.net/browse/JDK-8073139
  ****************************

  apparently there was a decision to NOT give the architecture a unique
  name, and that is inconstant with other JDK/JRE's, and it breaks a LOT
  of code.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/1438575/+subscriptions