[ https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125978#comment-14125978 ]
Colin Patrick McCabe commented on HADOOP-11064: ----------------------------------------------- bq. This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless rebuilt and repackaged with the hadoop- 2.6 JARs I don't follow. What is to rebuild? If you put the Hadoop 2.6 jars on the classpath and the hadoop 2.6 libhadoop.so on the classpath, your application should work. bq. Backward compatibility within a major version is usually expected from a user perspective. As Todd mentioned, we don't support mixing Hadoop 2.4 and Hadoop 2.6 jars on the same CLASSPATH. Similarly, we don't support mixing a libhadoop.so from one version with a libhadoop.so from another version. Backwards compatibility refers to compatibility with the public APIs, not compatibility with internal, non-public APIs. There's been a few of these jiras recently where people seem to want to put multiple versions of libhadoop.so on their classpath and expect it to work (I guess it would be hadoop.dll on Windows). I don't understand the motivation for doing this-- can't the launcher scripts for Windows simply set up the CLASSPATH and LD_LIBRARY_PATH appropriately for the version being launched? What am I missing? If it's absolutely, positively necessary to support throwing multiple versions of the libhadoop library on the classpath at once, we could inject the version into the library name / version info. > UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 > method changes > -------------------------------------------------------------------------------------- > > Key: HADOOP-11064 > URL: https://issues.apache.org/jira/browse/HADOOP-11064 > Project: Hadoop Common > Issue Type: Bug > Components: native > Affects Versions: 2.6.0 > Environment: Hadoop 2.6 cluster, trying to run code containing hadoop > 2.4 JARs > Reporter: Steve Loughran > Priority: Blocker > > The private native method names and signatures in {{NativeCrc32}} were > changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed > link errors when they try to perform checksums. > This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless > rebuilt and repackaged with the hadoop- 2.6 JARs -- This message was sent by Atlassian JIRA (v6.3.4#6332)