ORC-552 fix c++ for centos6.

[omalley]

Fix some compilation items on different compilers:

• Add -Wno-c++2a-compat for new clang compilers.
• Change the column printer parameter name to _buffer so that it doesn't hide the field.
• Change the capacity parameter name to _capacity so that it doesn't hide the field.
• Replace the emplace with insert so that it works on centos 6.
• Replace the for in loop for centos 6.
• Make TestColumnReader ignore parentheses warnings.
• Make snappy use lib instead of lib64 for the library directory name for centos 8.

[majetideepak]

does Clang have a 11.0 release?

[omalley]

Ok, the problem was with the MacOS Clang, which reports itself as:

omalley@dhcp-10-16-1-45> clang --version
Apple clang version 11.0.0 (clang-1100.0.33.8)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

I see your point that there isn't an upstream clang 11. I'm not sure what Apple is doing with their version numbers or the right way to detect it.

[majetideepak]

Yeah, I think Apple uses the XCode version.
Instead of CMAKE_CXX_COMPILER_VERSION should we use
"${COMPILER_VERSION_FULL}" MATCHES ".*clang-11"

[majetideepak]

Source: https://github.com/apache/arrow/blob/master/cpp/cmake_modules/CompilerInfo.cmake#L54

[omalley]

I used CMAKE_HOST_APPLE and the CMAKE_CXX_COMPILER_VERSION > 11. No doubt when some other OS is using clang 8?, we'll need to generalize it.

[omalley]

On MacOS Mojave (10.14), COMPILER_VERSION_FULL is undefined on cmake...

[omalley]

Ah, I see now that they are using the compiler itself to get that value. Current XCode doesn't match their patterns. :(

[majetideepak]

+1 LGTM