[jira] [Updated] (HADOOP-8037) Binary tarball does not preserve platform info for native builds, and fails to provide needed symlinks for libhadoop.so

["Matt Foley (Updated) (JIRA)" <ji...@apache.org>]

     [ 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