You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by "Stephen Watt (JIRA)" <ji...@apache.org> on 2010/08/24 21:50:17 UTC

[jira] Created: (HADOOP-6923) Native Libraries do not load if a different platform signature is returned from org.apache.hadoop.util.PlatformName

Native Libraries do not load if a different platform signature is returned from org.apache.hadoop.util.PlatformName
-------------------------------------------------------------------------------------------------------------------

                 Key: HADOOP-6923
                 URL: https://issues.apache.org/jira/browse/HADOOP-6923
             Project: Hadoop Common
          Issue Type: Bug
          Components: native
    Affects Versions: 0.20.2, 0.20.1, 0.20.0
         Environment: SLES 10, IBM Java 6, Apache Hadoop 0.20.x
            Reporter: Stephen Watt
             Fix For: 0.20.3


The bin/hadoop script has an environment variable called JAVA_PLATFORM which is set to to the results returned by org.apache.hadoop.util.PlatformName . These results are sometimes unique to the JRE being used. Although the value returned for 64 Bit Sun/Oracle Java and 64 Bit IBM Java is the same, it is different for the corresponding 32 Bit JREs.
The issue is that the value returned is used in creating the path to the native libraries on disk, i.e ${HADOOP_COMMON_HOME}/lib/native/${JAVA_PLATFORM}

Since the path on disk is fixed with the Sun JRE value /lib/native/Linux-i386-32 it therefore fails when it attempts to load the native libraries with the value returned with 32 Bit IBM Java, /lib/native/Linux-x86-32

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


RE: [jira] Created: (HADOOP-6923) Native Libraries do not load if a different platform signature is returned from org.apache.hadoop.util.PlatformName

Posted by "Segel, Mike" <ms...@navteq.com>.
This may seem like a silly question... 
Is there anyone using a 32bit JRE environment these days?

Also I notice this is for 0.20.3  is this still an issue in 0.89 or 0.20.6?

I really am curious if anyone outside of IBM is using 32bit Java in any capacity w hadoop? 

Thx

-Mike


-----Original Message-----
From: Stephen Watt (JIRA) [mailto:jira@apache.org] 
Sent: Tuesday, August 24, 2010 2:50 PM
To: common-dev@hadoop.apache.org
Subject: [jira] Created: (HADOOP-6923) Native Libraries do not load if a different platform signature is returned from org.apache.hadoop.util.PlatformName

Native Libraries do not load if a different platform signature is returned from org.apache.hadoop.util.PlatformName
-------------------------------------------------------------------------------------------------------------------

                 Key: HADOOP-6923
                 URL: https://issues.apache.org/jira/browse/HADOOP-6923
             Project: Hadoop Common
          Issue Type: Bug
          Components: native
    Affects Versions: 0.20.2, 0.20.1, 0.20.0
         Environment: SLES 10, IBM Java 6, Apache Hadoop 0.20.x
            Reporter: Stephen Watt
             Fix For: 0.20.3


The bin/hadoop script has an environment variable called JAVA_PLATFORM which is set to to the results returned by org.apache.hadoop.util.PlatformName . These results are sometimes unique to the JRE being used. Although the value returned for 64 Bit Sun/Oracle Java and 64 Bit IBM Java is the same, it is different for the corresponding 32 Bit JREs.
The issue is that the value returned is used in creating the path to the native libraries on disk, i.e ${HADOOP_COMMON_HOME}/lib/native/${JAVA_PLATFORM}

Since the path on disk is fixed with the Sun JRE value /lib/native/Linux-i386-32 it therefore fails when it attempts to load the native libraries with the value returned with 32 Bit IBM Java, /lib/native/Linux-x86-32

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above.  If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited.  If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.