[ https://issues.apache.org/jira/browse/ARROW-17110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17568126#comment-17568126 ]
H. Vetinari edited comment on ARROW-17110 at 7/18/22 5:17 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. Centos 7 has the devtoolset backports until GCC 11 (except aarch where it's GCC 10) though... These are obviously available & in use for the manylinux images, and I think they're a very much acceptable requirement for users on such old platforms. > I agree that for now conda-forge can simply build using C++17. Just before > [because?] the minimum version for Arrow is C++11 doesn't mean you are > forbidden to use a newer one :-D Well, I would like to avoid breaking your CI if possible. :) And as I tried to explain, if conda-forge switches to C++17 (especially on windows) while you still try to compile with C++11, breakage is all-but-guaranteed. PS. I hate the JIRA text -parser- mangler with a burning passion :O was (Author: h-vetinari): > 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. Centos 7 has the devtoolset backports until GCC 11 (except aarch where it's GCC 10) though... These are obviously available & in use for the manylinux images, and I think they're a very much acceptable requirement for users on such old platforms. > I agree that for now conda-forge can simply build using C\+\+17. Just before > [because?] the minimum version for Arrow is C\+\+11 doesn't mean you are > forbidden to use a newer one :-D Well, I would like to avoid breaking your CI if possible. :) And as I tried to explain, if conda-forge switches to C\+\+17 (especially on windows) while you still try to compile with C\+\+11, breakage is all-but-guaranteed. PS. I hate the JIRA parser with a burning passion :O > [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)