-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[C++][R] abseil fails to build with gcc-13 #36969
Comments
@assignUser - I don't suppose you've got any idea why this might have started failing? |
hm that reads like a version mismatch or something... I'll check it out |
I don't think this is abseil related as the files in question haven't had changes in a few years ...it looks like there was a major docker upgrade on azure from 20.x to 23.x |
looks like the r-base image bumped gcc from 12 to 13 that might be it? |
can reproduce the error locally with gcc 13, will investigate but as cran has multiple machines running 13 this is likely a blocker for the next 13 rc HEAD abseil build without a problem so we might just need to bump the abseil version (which iirc is potentially difficult?) |
I think these are the relevant issues that are cause by gcc 13 https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes
|
We actually don't have any CI build with gcc 13 (other than test-r-library-r-base-latest and test-r-depsource-bundled) so this is an issue not only affecting R but was missed thus far. |
…c-13 (#37147) ### Rationale for this change Currently a naive `install.packages("arrow")` will result in a failed build if gcc-13 is the compiler. This is because we include GCS by default on this type of build (bundled). CRAN's check farm includes at least one system where gcc-13 is the compiler and so we can't error or suggest a user workaround. ### What changes are included in this PR? This PR explicitly sets the relevant environment variable if the compiler version string contains "g++" and "13.XX.XX". This is admittedly crude; however, the alternative of updating Abseil results in a cascading set of changes that may break other parts of Arrow. Few if any actual users will build the Arrow R package from source using gcc-13, so this has a much lower footprint (and a workaround: you can just set the ARROW_GCS environment variable + custom abseil location yourself before building if you do, in fact, want to attempt this). ### Are these changes tested? Tested via crossbow (see below). ### Are there any user-facing changes? No. * Closes: #36969 Authored-by: Dewey Dunnington <[email protected]> Signed-off-by: Jacob Wujciak-Jens <[email protected]>
…c-13 (#37147) ### Rationale for this change Currently a naive `install.packages("arrow")` will result in a failed build if gcc-13 is the compiler. This is because we include GCS by default on this type of build (bundled). CRAN's check farm includes at least one system where gcc-13 is the compiler and so we can't error or suggest a user workaround. ### What changes are included in this PR? This PR explicitly sets the relevant environment variable if the compiler version string contains "g++" and "13.XX.XX". This is admittedly crude; however, the alternative of updating Abseil results in a cascading set of changes that may break other parts of Arrow. Few if any actual users will build the Arrow R package from source using gcc-13, so this has a much lower footprint (and a workaround: you can just set the ARROW_GCS environment variable + custom abseil location yourself before building if you do, in fact, want to attempt this). ### Are these changes tested? Tested via crossbow (see below). ### Are there any user-facing changes? No. * Closes: #36969 Authored-by: Dewey Dunnington <[email protected]> Signed-off-by: Jacob Wujciak-Jens <[email protected]>
@assignUser, is there a replacement issue, now that #37066 was closed unmerged? #37147 is a work-around, not a solution. Abseil should be kept up-to-date like any other dependency. |
With our move to cmake 3.16 as minumum version we can finally use FetchContent instead of ep, this will make updating dependencies much easier as we do not have to recreate the internal target tree of the dependency as we currently do. It should also be possible to move singular dependencies to FC (caveat is that we have to move all of it's dependencies to FC as well afaik). I don't think there is a general issue for this or for abseil specifically. |
… on gcc-13 (apache#37147) ### Rationale for this change Currently a naive `install.packages("arrow")` will result in a failed build if gcc-13 is the compiler. This is because we include GCS by default on this type of build (bundled). CRAN's check farm includes at least one system where gcc-13 is the compiler and so we can't error or suggest a user workaround. ### What changes are included in this PR? This PR explicitly sets the relevant environment variable if the compiler version string contains "g++" and "13.XX.XX". This is admittedly crude; however, the alternative of updating Abseil results in a cascading set of changes that may break other parts of Arrow. Few if any actual users will build the Arrow R package from source using gcc-13, so this has a much lower footprint (and a workaround: you can just set the ARROW_GCS environment variable + custom abseil location yourself before building if you do, in fact, want to attempt this). ### Are these changes tested? Tested via crossbow (see below). ### Are there any user-facing changes? No. * Closes: apache#36969 Authored-by: Dewey Dunnington <[email protected]> Signed-off-by: Jacob Wujciak-Jens <[email protected]>
This issue was blocking me from doing some development work so I changed the Abseil build to include a patch to work around it: adamreeve@ed44152 I don't think it would make sense to make a PR with this as the proper fix is to upgrade Abseil, but I thought I'd post it here in case it helps anyone else. |
### Rationale for this change When trying to compile Arrow with GCC 13, it fails due to ABSEIL missing a `<cstdint>` include, this PR addresses the issue by adding the missing include. There have been past reports for this issue too: #36969 This is a more minimal fix that tries to avoid the complexity of previous attempts like #43147 and #37066 which involved updating Abseil and facing additional issues to fix. ### What changes are included in this PR? Add the missing include when GCC>=13 ### Are these changes tested? They are tested by the existing compile infrastructure and testsuite and by adding a new GCC-13 based CPP test environment for bundled builds. ### Are there any user-facing changes? No, all behaviours should remain the same * GitHub Issue: #43228 Lead-authored-by: Alessandro Molina <[email protected]> Co-authored-by: Sutou Kouhei <[email protected]> Signed-off-by: Jacob Wujciak-Jens <[email protected]>
### Rationale for this change When trying to compile Arrow with GCC 13, it fails due to ABSEIL missing a `<cstdint>` include, this PR addresses the issue by adding the missing include. There have been past reports for this issue too: #36969 This is a more minimal fix that tries to avoid the complexity of previous attempts like #43147 and #37066 which involved updating Abseil and facing additional issues to fix. ### What changes are included in this PR? Add the missing include when GCC>=13 ### Are these changes tested? They are tested by the existing compile infrastructure and testsuite and by adding a new GCC-13 based CPP test environment for bundled builds. ### Are there any user-facing changes? No, all behaviours should remain the same * GitHub Issue: #43228 Lead-authored-by: Alessandro Molina <[email protected]> Co-authored-by: Sutou Kouhei <[email protected]> Signed-off-by: Jacob Wujciak-Jens <[email protected]>
On ubuntu-24.04, we have gcc 13, and abseil (grpc's dependency) fails to build with this version of gcc. Thus, we're building with gcc 12. [1] In the original Dockerfile, falco is installed using apt. We're creating a .deb file for Falco and then unpack it into the part install folder. This makes it easier add all the necessary files into the rock. [1]: apache/arrow#36969
On ubuntu-24.04, we have gcc 13, and abseil (grpc's dependency) fails to build with this version of gcc. Thus, we're building with gcc 12. [1] In the original Dockerfile, falco is installed using apt. We're creating a .deb file for Falco and then unpack it into the part install folder. This makes it easier add all the necessary files into the rock. [1]: apache/arrow#36969
On ubuntu-24.04, we have gcc 13, and abseil (grpc's dependency) fails to build with this version of gcc. Thus, we're building with gcc 12. [1] In the original Dockerfile, falco is installed using apt. We're creating a .deb file for Falco and then unpack it into the part install folder. This makes it easier add all the necessary files into the rock. [1]: apache/arrow#36969
On ubuntu-24.04, we have gcc 13, and abseil (grpc's dependency) fails to build with this version of gcc. Thus, we're building with gcc 12. [1] In the original Dockerfile, falco is installed using apt. We're creating a .deb file for Falco and then unpack it into the part install folder. This makes it easier add all the necessary files into the rock. [1]: apache/arrow#36969
On ubuntu-24.04, we have gcc 13, and abseil (grpc's dependency) fails to build with this version of gcc. Thus, we're building with gcc 12. [1] In the original Dockerfile, falco is installed using apt. We're creating a .deb file for Falco and then unpack it into the part install folder. This makes it easier add all the necessary files into the rock. [1]: apache/arrow#36969
On ubuntu-24.04, we have gcc 13, and abseil (grpc's dependency) fails to build with this version of gcc. Thus, we're building with gcc 12. [1] In the original Dockerfile, falco is installed using apt. We're creating a .deb file for Falco and then unpack it into the part install folder. This makes it easier add all the necessary files into the rock. [1]: apache/arrow#36969
Describe the bug, including details regarding any error messages, version, and platform.
e.g. https://dev.azure.com/ursacomputing/crossbow/_build/results?buildId=52112&view=logs&j=0da5d1d9-276d-5173-c4c4-9d4d4ed14fdb&t=d9b15392-e4ce-5e4c-0c8c-b69645229181&l=1975
Component(s)
R
The text was updated successfully, but these errors were encountered: