[ https://issues.apache.org/jira/browse/ARROW-17110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17568100#comment-17568100 ]
Neal Richardson edited comment on ARROW-17110 at 7/18/22 4:41 PM: ------------------------------------------------------------------ Slight correction: GCC 4.8 is not an R requirement. It comes from CentOS 7, where it is the default compiler. We do happen to get a number of bug reports from R users on CentOS 7, though. R 3.6 on Windows used an odd gcc 4.9 mingw compiler, and that's the main source of "R requires an old compiler". But we already disable many features on R < 4.0 on Windows, and conditionally disabling more is not a problem. (GCS filesystem support, which uses abseil, is one of those already.) We could drop support for R 3.6 now, but since we can just disable features on the build, we haven't been forced to do so yet. CRAN checks are now all running gcc 8 or newer: https://cran.r-project.org/web/checks/check_flavors.html We have CI that builds arrow on C\+\+17 (and maybe also 14?). I think Homebrew also bumped up building arrow with C\+\+17 to match abseil (or maybe that's still in the copy of the formula we test in apache/arrow). We also have an open PR to add Azure Blob Storage, which will require C\+\+14: https://github.com/apache/arrow/pull/12914/files#r899724290. So maybe the solution for the abseil issue is to require the newer C\+\+ standard if using abseil built with it? was (Author: npr): Slight correction: GCC 4.8 is not an R requirement. It comes from CentOS 7, where it is the default compiler. We do happen to get a number of bug reports from R users on CentOS 7, though. R 3.6 on Windows used an odd gcc 4.9 mingw compiler, and that's the main source of "R requires an old compiler". But we already disable many features on R < 4.0 on Windows, and conditionally disabling more is not a problem. (GCS filesystem support, which uses abseil, is one of those already.) We could drop support for R 3.6 now, but since we can just disable features on the build, we haven't been forced to do so yet. CRAN checks are now all running gcc 8 or newer: https://cran.r-project.org/web/checks/check_flavors.html We have CI that builds arrow on C++17 (and maybe also 14?). I think Homebrew also bumped up building arrow with C++17 to match abseil (or maybe that's still in the copy of the formula we test in apache/arrow). We also have an open PR to add Azure Blob Storage, which will require C++14: https://github.com/apache/arrow/pull/12914/files#r899724290. So maybe the solution for the abseil issue is to require the newer C++ standard if using abseil built with it? > [C++] Move away from C++11 > -------------------------- > > Key: ARROW-17110 > URL: https://issues.apache.org/jira/browse/ARROW-17110 > Project: Apache Arrow > Issue Type: Task > Components: C++ > Reporter: H. Vetinari > Priority: Major > > The upcoming abseil release has dropped support for C++11, so > {_}eventually{_}, arrow will have to follow. More details > [here|https://github.com/conda-forge/abseil-cpp-feedstock/issues/37]. > Relatedly, when I > [tried|https://github.com/conda-forge/abseil-cpp-feedstock/pull/25] to switch > abseil to a newer C++ version on windows, things apparently broke in arrow > CI. This is because the ABI of abseil is sensitive to the C++ standard that's > used to compile, and google only supports a homogeneous version to compile > all artefacts in a stack. This creates some friction with conda-forge (where > the compilers are generally much newer than what arrow might be willing to > impose). For now, things seems to have worked out with arrow > [specifying|https://github.com/apache/arrow/blob/897a4c0ce73c3fe07872beee2c1d2128e44f6dd4/cpp/cmake_modules/SetupCxxFlags.cmake#L121-L124] > C\+\+11 while conda-forge moved to C\+\+17 - at least on unix, but windows > was not so lucky. > Perhaps people would therefore also be interested in collaborating (or at > least commenting on) this > [issue|https://github.com/conda-forge/abseil-cpp-feedstock/issues/29], which > should permit more flexibility by being able to opt into given standard > versions also from conda-forge. -- This message was sent by Atlassian Jira (v8.20.10#820010)