[
https://issues.apache.org/jira/browse/HADOOP-7405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051800#comment-13051800
]
Allen Wittenauer commented on HADOOP-7405:
------------------------------------------
That's an interesting idea. How would this work? Are you thinking that during
the native load, we detect what soversion got loaded and then base available
functionality on that?
I was thinking (far) down the road that we could basically dlopen() modules
from within libhadoop.so. Then as functionality got ported, one would just
drop in the appropriate shared lib. This also makes codec support very
interesting: instead of having different bootstrap code for every codec, one
could generalize it more than it is today.
> libhadoop is all or nothing
> ---------------------------
>
> Key: HADOOP-7405
> URL: https://issues.apache.org/jira/browse/HADOOP-7405
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
> Affects Versions: 0.20.203.0, 0.23.0
> Environment: Everything not Linux
> Reporter: Allen Wittenauer
> Priority: Blocker
> Labels: regression
>
> As a result of a ton of new code in libhadoop being added in 0.20.203/0.22, a
> lot of features that used to work no longer do reliably. The most common
> problem is native compression, but other issues such as Mac OS X's group
> support broke as well. The native code checks need to be refactored such
> that libhadoop.so should report what it supports rather than having the
> Java-side assume that if it loads, it is all supported. This would allow us
> to stub routines until they've been vetted, removing the chances of such
> regressions appearing in the future.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
