-
-
Notifications
You must be signed in to change notification settings - Fork 26
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
Force ppc64le builds to use gcc 13 #139
Conversation
…nda-forge-pinning 2023.10.17.07.56.56
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
I made some guess as to how to get ppc64le to build on travis. Let me know (if the builds themselves don't) how this could/should theoretically be done. As mentioned in the other PR and issues, it seems there may be errors in the emulated ppc64le so we'll try native on travis. |
Hm the output still shows the invalid result:
(the -3.54 in the above is bad). I don't know enough about travis but I think the configuration I did is telling it to use ppc64le natively...right? Edit:
|
That's my understanding, though my expertise is also somewhat limited. |
Note: Windows is failing just because I was lazy setting the debug env vars. |
Well...that's what I get for copying a patch from upstream |
@rouault Sorry to pull you into this PR, but it might just be easier to discuss this this way: I've added your test from OSGeo/PROJ#3923 as a patch to this feedstock. It fails on the travis ppc64le build. Conda-forge's CI scripts and build process is much more complicated than PROJ's travis setup. For reference: PROJ: conda-forge: The conda-forge build should be "native" but it does run through docker compared to PROJ's direct execution. @xylar let me know if there is some further option you can think of to run even more directly on the native ppc64le. I assume docker is smart enough to realize that it doesn't need to emulate the architecture at all (ppc running on ppc). The worker/build information shows that they are both running ppc64le. Otherwise @rouault, conda-forge is still using: Do you imagine that this could be causing these ppc issues? |
no, that's totally unrelated. |
another difference is that PROJ's travis setup was using Ubuntu Bionic (18.04), so a much older build toolchain than conda-forge builds. I've updated OSGeo/PROJ#3923 to use Jammy (22.04) |
Tests also pass on Jammy: https://app.travis-ci.com/github/OSGeo/PROJ/builds/266655965 (the final failure is unrelated. The test suite success status is at https://app.travis-ci.com/github/OSGeo/PROJ/builds/266655965#L789) |
@xylar or other conda-forge expert: Is there an existing script/configuration for running linux builds natively (no docker)? I don't see any here: So I'm trying to hack my own just to get something working in this feedstock that passes the ppc64le test. Then I'll work from there to figure out what's causing the differences between here and upstream tests (docker build itself, conda-forge dependencies, etc). |
@djhoese, I don't think so, but I'm ready to be corrected by a conda-forge expert. |
@conda-forge-admin restart ci |
@ocefpaf same question for you if you're around and know the answer ^ |
I'm quite removed from the compiler choices in conda-forge and maybe @isuruf can comment more. While I believe it is possible we need to be careful with compatibility. With that said, I think I already said this but I'll say it again, we don't really make ppc64le a priority. I'm OK with just dropping it going forward and re-adding when a new compiler is available everywhere. |
I don't have any personal stake in ppc support so I don't think I should have a say in the outcome. I was just annoyed that something that seemed to be working before was now not working. I do think this failure is an important one. @rouault what is your opinion on this test (or one like it) being included in PROJ's tests? It doesn't seem to be conda-forge specific anymore, but rather gcc 12 as the problem. I'd also be fine cleaning up my patch in this repository to only have the test here and/or update the shell-level Thanks @isuruf! |
why not, but it needs some care as we try to make PROJ's test not to rely too much on the network (some builds might have curl disabled). If that's indeed a compiler bug, it is hard to correlate that with functional tests... |
Will the test you added in OSGeo/PROJ#3923 silently skip if network isn't available or does it cause the test to fail in those environments? I'm thinking what I might do is do a simple shell-level test in conda-forge for |
it would fail |
…nda-forge-pinning 2023.10.19.17.00.48
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't say my proj expertise is deep but this fix seems very reasonable and I think we want to get it in as soon as possible.
Awesome debugging work @djhoese! And thanks to all that helped and reviewed this one!! |
Thanks for the hard work digging in @djhoese ! |
Replaces #137
Update: This PR was originally just for testing to find out why ppc64le builds were producing inconsistent results (ex.
cs2cs
). The problem was whittled down to gcc 12 being a problem. Rather than using the older gcc 11 (which works fine), this PR now changes the compiler to be gcc 13.I've also added a test to the recipe that should fail if things go wrong again in a future version of the compiler.
Checklist
0
(if the version changed)conda-smithy
(Use the phrase@conda-forge-admin, please rerender
in a comment in this PR for automated rerendering)