[
https://issues.apache.org/jira/browse/HADOOP-12036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14565779#comment-14565779
]
Colin Patrick McCabe commented on HADOOP-12036:
-----------------------------------------------
bq. What about the test_bulk_crc32 app for example, is that multithreaded? If
it's OK to use -pthread on that then I think -pthread can safely be added to
the global flags, as you suggest.
Some test programs aren't multithreaded, but there is no harm in passing
{{\-pthread}} in all cases. The overhead is extremely minimal, and it brings
the test programs closer to what they're supposed to test (which is real hadoop
performance / correctness in a multi-threaded environment.)
The main thing to keep in mind is that we don't want JNI linked into programs
unless they actually use JNI. But that shouldn't be an issue based on my
reading of the patch.
bq. I've put in a modification that allows you to preset a variable,
GCC_SHARED_FLAGS. If it's not set it currently defaults to "-g -O2 -Wall", if
it is OK to do so I'll change that to "-g -O2 -Wall -pthread
-D_LARGEFILE_SOURCE", then the hadoop-yarn-project CMakeLists.txt can simply
set it appropriately before including HadoopCommon.cmake
Doesn't that mean that if you change {{-O2}} to {{-O3}} in the common code,
yarn will be unaffected? I would prefer to override only the thing that needs
to be different, aka {{_LARGEFILE_SOURCE}}.
bq. Sorry to sound like a stuck record but you still haven't given me what I
consider to be a satisfactory reason why _GNU_SOURCE should be set as a
compiler command-line flag, even on Linux. Just to be completely clear, I'm not
intending to just remove it and have stuff blow up on Linux, I'm intending to
go through all the source and add the necessary #define/#undef blocks so that
all the Linux-specific code continues to work. Stopping this practice will help
keep the source portable, as I've explained at length in HADOOP-11997.
Everyone agrees that not setting _GNU_SOURCE (or setting it in a more limited
way) *won't* enforce portability. For example, you still get the non-POSIX
definition of {{strerror_r}}. You still have all the actually non-portable
things in the places they are needed (i.e. cgroups, etc.).
On the other hand, everyone agrees that having a nightly build on Solaris / BSD
/ whatever *will* enforce portability.
>From experience, trying to conditionally set {{_GNU_SOURCE}} is a huge pain in
>the rear for everyone, leads to mysterious compile errors, and makes life
>difficult for new contributors. There's just no point.
If you put the energy and effort that is going into worrying about
{{_GNU_SOURCE}} into creating a Solaris or BSD nightly build, you would have a
guarantee that portability would not regress. It is a waste of time to worry
about {{_GNU_SOURCE}}, although if you want to avoid setting it on Solaris
(just to keep things "tidy") that is fine.
> Consolidate all of the cmake extensions in one directory
> --------------------------------------------------------
>
> Key: HADOOP-12036
> URL: https://issues.apache.org/jira/browse/HADOOP-12036
> Project: Hadoop Common
> Issue Type: Sub-task
> Reporter: Allen Wittenauer
> Assignee: Alan Burlison
> Attachments: prototype01.txt
>
>
> Rather than have a half-dozen redefinitions, custom extensions, etc, we
> should move them all to one location so that the cmake environment is
> consistent between the various native components.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
