hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin Patrick McCabe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-11505) Various native parts use bswap incorrectly and unportably
Date Tue, 12 Jan 2016 19:39:40 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-11505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15094618#comment-15094618

Colin Patrick McCabe commented on HADOOP-11505:

bq. Generating multiple copies of the same header file and spreading them around the build
tree seems pretty undesirable to me, which is what we'd end up with if we abstract this into
a CMake module.

Generating the {{config.h}} header takes a really small amount of time.  I would much rather
just have each CMakeLists.txt generate its own {{config.h}}, than have to build {{hadoop-common}}
all the time (which takes a full 20 seconds on my machine).  This might be an example of a
micro-optimization that blocks a much bigger macro-optimization.

bq. Additionally, for lz4, the pom.xml file does the magic to make it work:

It seems like Yetus' change detection will fail if we make a change to lz4, though, right?
 It will not trigger {{hadoop-mapreduce-client-nativetask}} to be built.

> Various native parts use bswap incorrectly and unportably
> ---------------------------------------------------------
>                 Key: HADOOP-11505
>                 URL: https://issues.apache.org/jira/browse/HADOOP-11505
>             Project: Hadoop Common
>          Issue Type: Bug
>    Affects Versions: 3.0.0
>            Reporter: Colin Patrick McCabe
>            Assignee: Alan Burlison
>             Fix For: 3.0.0
>         Attachments: HADOOP-11505.001.patch, HADOOP-11505.003.patch, HADOOP-11505.004.patch,
HADOOP-11505.005.patch, HADOOP-11505.006.patch, HADOOP-11505.007.patch
> hadoop-mapreduce-client-nativetask fails to use x86 optimizations in some cases.  Also,
on some alternate, non-x86, non-ARM architectures the generated code is incorrect.  Thanks
to Steve Loughran and Edward Nevill for finding this.

This message was sent by Atlassian JIRA

View raw message