Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Date: Wed, 27 May 2015 10:40:17 +0000 (UTC)
From: "Alan Burlison (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.12831046.1432049246000.37477.1432723217397@Atlassian.JIRA>
In-Reply-To: <JIRA.12831046.1432049246000@Atlassian.JIRA>
References: <JIRA.12831046.1432049246000@Atlassian.JIRA>
 <JIRA.12831046.1432049246167@arcas>
Subject: [jira] [Commented] (HADOOP-11997) CMake CMAKE_C_FLAGS are
 non-portable
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Alan Burlison commented on HADOOP-11997:
----------------------------------------

I've currently modified the various CMake files to set RelWithDebInfo if no build mode is specified, I'll remove that and just set CFLAGS explicitly if that's considered to be a better option.

However the -D_GNU_SOURCE flag is toxic to portability and will just repeatedly cause portability breakage if it's left in so I'm intending to remove it and explicitly bracket all such Linux-specific code in the source with #define/#undef blocks. That will mean that people doing port work to other platforms will have an easier time of it in future.

Adding Solaris Studio compiler support is a long-term goal but initially just targeting gcc is the simplest option so I'm proposing just to add Solaris/gcc support initially. Note also that Solaris Studio is also available on Linux (http://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/index-jsp-141149.html) so when Studio support is added it needs to be done separately from the platform detection in any case.

> CMake CMAKE_C_FLAGS are non-portable
> ------------------------------------
>
>                 Key: HADOOP-11997
>                 URL: https://issues.apache.org/jira/browse/HADOOP-11997
>             Project: Hadoop Common
>          Issue Type: Sub-task
>          Components: build
>    Affects Versions: 2.7.0
>         Environment: All
>            Reporter: Alan Burlison
>            Assignee: Alan Burlison
>            Priority: Critical
>
> hadoop-common-project/hadoop-common/src/CMakeLists.txt (https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/CMakeLists.txt#L110) contains the following unconditional assignments to CMAKE_C_FLAGS:
> set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -g -Wall -O2")
> set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -D_REENTRANT -D_GNU_SOURCE")
> set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64")
> There are several issues here:
> 1. "-D_GNU_SOURCE" globally enables the use of all Linux-only extensions in hadoop-common native source. This is probably a major contributor to the poor cross-platform portability of Hadoop native code to non-Linux platforms as it makes it easy for developers to use non-portable Linux features without realising. Use of Linux-specific features should be correctly bracketed with conditional macro blocks that provide an alternative for non-Linux platforms.
> 2. "-g -Wall -O2" turns on debugging for all builds, I believe the correct mechanism is to set the CMAKE_BUILD_TYPE CMake variable. If it is still necessary to override CFLAGS it should probably be done conditionally dependent on the value of CMAKE_BUILD_TYPE.
> 3. "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" On Solaris these flags are only needed for largefile support in ILP32 applications, LP64 applications are largefile by default. I believe the same is true on Linux, so these flags are harmless but redundant for 64-bit compilation.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)