[ 
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)

Reply via email to