[
https://issues.apache.org/jira/browse/HADOOP-8037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Foley updated HADOOP-8037:
-------------------------------
Summary: Binary tarball does not preserve platform info for native builds,
and fails to provide needed symlinks for libhadoop.so (was: Binary tarball
does not preserve platform info for native builds)
There's a secondary issue: The code fragment in bin-package that does the
stripping of platform names from the directory paths is this: {code}
<move todir="${dist.dir}/lib" flatten="true">
<fileset dir="${dist.dir}/native">
<include name="*/*"/>
</fileset>
</move>
<delete dir="${dist.dir}/native"/>
{code}
This usage of the <move> ant task fails to grab the symlinks that are important
for libhadoop. Prior to this, the platform-specific subdirectories contain,
e.g., {code}
./hadoop-1.0.1/native/Linux-i386-32/libhadoop.so
./hadoop-1.0.1/native/Linux-i386-32/libhadoop.so.1
./hadoop-1.0.1/native/Linux-i386-32/libhadoop.so.1.0.0
{code}
However, after the projection is done by the <move> task, we are left with only
{code}
hadoop-1.0.1/lib/libhadoop.so.1.0.0
{code}
The other two files were symlinks to libhadoop.so.1.0.0, and did not get moved.
As a result, the rpm with native build fails to provide the needed libhadoop.so.
This could be opened as a separate Jira, but both need to be solved in the same
area of code, so I'm leaving them together. I'll add to the bug title.
> Binary tarball does not preserve platform info for native builds, and fails
> to provide needed symlinks for libhadoop.so
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: HADOOP-8037
> URL: https://issues.apache.org/jira/browse/HADOOP-8037
> Project: Hadoop Common
> Issue Type: Bug
> Components: build
> Affects Versions: 1.0.1
> Reporter: Matt Foley
> Assignee: Giridharan Kesavan
>
> The source tarball uses "package" ant target, which includes both sets of
> native builds (32 and 64 bit libraries), under subdirectories that are named
> for the supported platform, so you can tell what they are.
> The binary tarball uses the "bin-package" ant target, which projects both
> sets of native builds into a single directory, stripping out the platform
> names from the directory paths. Since the native built libraries have
> identical names, only one of each survives the process. Afterward, there is
> no way to know whether they are intended for 32 or 64 bit environments.
> It seems to be done this way as a step toward building the rpm and deb
> artifacts. But the rpms and debs are self-identifying as to the platform
> they were built for, and contain only one set of libs each, while the binary
> tarball isn't. The binary tarball should have the same platform-specific
> subdirectories that the full tarball does; but this means that the rpm and
> deb builds have to be more careful about include/exclude specs for what goes
> into those artifacts.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
