Return-Path: 
 <mapreduce-issues-return-41978-apmail-hadoop-mapreduce-issues-archive=hadoop.apache.org@hadoop.apache.org>
X-Original-To: apmail-hadoop-mapreduce-issues-archive@minotaur.apache.org
Delivered-To: apmail-hadoop-mapreduce-issues-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id D8EEF9981
	for <apmail-hadoop-mapreduce-issues-archive@minotaur.apache.org>;
 Sat, 25 Feb 2012 00:54:12 +0000 (UTC)
Received: (qmail 5783 invoked by uid 500); 25 Feb 2012 00:54:12 -0000
Delivered-To: apmail-hadoop-mapreduce-issues-archive@hadoop.apache.org
Received: (qmail 5743 invoked by uid 500); 25 Feb 2012 00:54:12 -0000
Mailing-List: contact mapreduce-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:mapreduce-issues-help@hadoop.apache.org>
List-Unsubscribe: <mailto:mapreduce-issues-unsubscribe@hadoop.apache.org>
List-Post: <mailto:mapreduce-issues@hadoop.apache.org>
List-Id: <mapreduce-issues.hadoop.apache.org>
Reply-To: mapreduce-issues@hadoop.apache.org
Delivered-To: mailing list mapreduce-issues@hadoop.apache.org
Received: (qmail 5734 invoked by uid 99); 25 Feb 2012 00:54:12 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 25 Feb 2012 00:54:12 +0000
X-ASF-Spam-Status: No, hits=-2000.0 required=5.0
	tests=ALL_TRUSTED,T_RP_MATCHES_RCVD
X-Spam-Check-By: apache.org
Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 25 Feb 2012 00:54:10 +0000
Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116])
	by hel.zones.apache.org (Postfix) with ESMTP id 27F5D337D36
	for <mapreduce-issues@hadoop.apache.org>;
 Sat, 25 Feb 2012 00:53:49 +0000 (UTC)
Date: Sat, 25 Feb 2012 00:53:49 +0000 (UTC)
From: "Roman Shaposhnik (Updated) (JIRA)" <jira@apache.org>
To: mapreduce-issues@hadoop.apache.org
Message-ID: 
 <644525679.18207.1330131229165.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (MAPREDUCE-3890) Change to nodemanager build now
 requires 32-bit libraries
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394
X-Virus-Checked: Checked by ClamAV on apache.org


     [ https://issues.apache.org/jira/browse/MAPREDUCE-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Roman Shaposhnik updated MAPREDUCE-3890:
----------------------------------------

    Status: Patch Available  (was: Open)

Attaching a patch that makes it possible to build the container-executor binary that has the default system architecture. Just add -Dcontainer-executor.arch=" " to the build and you're done. This will unblock Bigtop packaging efforts and will let us use 0.23.1 as the basis of Hadoop RPM and DEBIAN packaging.

Feel free to modify to suit your needs. Or apply as is. The (unfortunate) default behavior of pretending that every workstation is fully configured with 32bit environment is preserved.
                
> Change to nodemanager build now requires 32-bit libraries
> ---------------------------------------------------------
>
>                 Key: MAPREDUCE-3890
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-3890
>             Project: Hadoop Map/Reduce
>          Issue Type: Bug
>          Components: build, mrv2
>    Affects Versions: 0.23.1
>         Environment: Centos 6, x86_64
>            Reporter: Ralph H Castain
>            Assignee: Ralph H Castain
>             Fix For: 0.23.2
>
>         Attachments: MAPREDUCE-3890.patch.txt
>
>
> Sometime during the last week, someone committed a change to:
> hadoop-mapreduce-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager/pom.xml
> that inserted a -m32 in:
>                <configureEnvironment>
>                  <property>
>                    <name>CFLAGS</name>
>                   <value>-DHADOOP_CONF_DIR=${container-executor.conf.dir} -m32</value>
> This breaks the build on 64-bit systems that do not have 32-bit libraries installed. The change was actually not required as 64-bit support for JNI and JVMs is readily available and installed by default on many 64-bit systems. Removing the flag results in a completed and functional build.
> If mandating 32-bit builds is desired, then a better solution would be to provide a configure flag such as -DHADOOP_32bit_MODE, perhaps with a corresponding flag for 64-bit. Regardless, locking the system to 32-bit builds seems a tad extreme.

--
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