[
https://issues.apache.org/jira/browse/HADOOP-8806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13455485#comment-13455485
]
Roman Shaposhnik commented on HADOOP-8806:
------------------------------------------
bq. [epel discussion]
I think this is a bit of a red herring here. I'm confident that libsnappy will
get into the distros with time and when this happens we have to be able to
offer a choice that is not -- recompile your libhadoop.so. The current
situation where libsnappy.so gets bundled with hadoop as a separate object that
can ignored (if needed) is ideal from that standpoint. Statically linking all
of it into the libhadoop.so is a hammer that I'd rather not use right away.
At this point the problem is that we've got 2 code path. One in
org.apache.hadoop.io.compress.snappy that does System.loadLibrary("snappy");
and is fine and the other one, apparently, in libhadoop.so that uses dlopen().
Would it be completely out of the question to focus on unifying the two?
> libhadoop.so: search java.library.path when calling dlopen
> ----------------------------------------------------------
>
> Key: HADOOP-8806
> URL: https://issues.apache.org/jira/browse/HADOOP-8806
> Project: Hadoop Common
> Issue Type: Improvement
> Reporter: Colin Patrick McCabe
> Priority: Minor
>
> libhadoop calls {{dlopen}} to load {{libsnappy.so}} and {{libz.so}}. These
> libraries can be bundled in the {{$HADOOP_ROOT/lib/native}} directory. For
> example, the {{-Dbundle.snappy}} build option copies {{libsnappy.so}} to this
> directory. However, snappy can't be loaded from this directory unless
> {{LD_LIBRARY_PATH}} is set to include this directory.
> Should we also search {{java.library.path}} when loading these libraries?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
