Inconsistent results on ppc64le on conda-forge with gcc 12 #3922
Labels
Comments
5 tasks
|
Please set I watched your thread in the feedstock and was wondering if this was just a |
|
I'll try out the debug flag (emulated builds take a bit), thanks. For my own reference, pyproj's build's tests force PROJ_NETWORK to if [ -f "${CONDA_PREFIX}/share/proj/copyright_and_licenses.csv" ]; then
# proj-data is installed because its license was copied over
export PROJ_NETWORK="OFF"
else
export PROJ_NETWORK="ON"
fias that license file doesn't seem to exist in the latest packages release. |
My guess would be that it is not UTM related. EPSG:26915 to EPSG:26715 involves NAD83 to NAD27 and hence grid shift files, whereas EPSG:3034 to EPSG:3035 remains in the ETRS89 datum |
|
Seeing some questionable warnings in the conda-forge build and I don't want to lose them, so putting them here: As for the PROJ_DEBUG=3 output. First run: Second run (good output): So the seemingly important part from the first run: But the second one, which also failed to get the |
rouault
added a commit
to rouault/PROJ
that referenced
this issue
Oct 16, 2023
rouault
added a commit
to rouault/PROJ
that referenced
this issue
Oct 16, 2023
|
the added test case works fine on native ppc64le (https://app.travis-ci.com/github/OSGeo/PROJ/jobs/611673341), which strongly reinforces my hypothesis of an emulation bug |
|
@rouault I'm still seeing the invalid results on travis and I think it is running natively. You can find the CI jobs here: conda-forge/proj.4-feedstock#139 And I'll repeat the output from my comment there: The first two lines are the transformation with 3034/3035. The next two are the |
|
As mentioned in the referenced conda-forge pull request, this seems to have come down to gcc 12 being used. gcc 11 (used in PROJ's builds, including #3923) seems to work fine. In the conda-forge PR I also got gcc 13 to work just fine. I'll see if conda-forge will accept that change. Meanwhile I was hoping a PROJ no-network friendly version of the test in #3923 could be merged in PROJ's tests to catch this if/when PROJ starts using gcc 12 in builds in the future. |
djhoese
changed the title
3 tasks
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Example of problem
First example works fine. Second transformation does not.
Problem description
Reference issue: conda-forge/proj.4-feedstock#137
As mentioned in the many issues related to this on the conda-forge feedstock repositories, there seems to be an issue when some transformations happen, but so far only seems to effect ppc64le systems (perhaps the only little endian platform tested on conda-forge). This was originally discovered with pyproj where ppc64le builds were added, but a single test (yes, just one) would fail with very incorrect results. However, it only seems to happen on the first execution of this command and only with specific CRSes (UTM EPSG codes so far).
Note in the above example how the first non-UTM transformation gives the same results the first and second time. The second transformation with the 26915 and 26715 EPSG codes produces an incorrect result in the first execution and then gives valid result in the second instance.
Note that I've tested this with running a
projcommand before thecs2csandcs2csstill has the same behavior. I've also done it withcs2cswith no arguments to show the usage/help message and the same behavior. In the above example runningcs2cswith the first transformation also doesn't seem to "initialize" something that the second set of transformations are dependent on.So far I've only tested this with conda-forge's build system (local docker-based emulated builds) mainly because getting ppc64le emulated builds working is a pain otherwise.
Expected Output
The same result both times:
Environment Information
proj): Seen with 9.3.0 and 9.2.1. Haven't tested beyond that.Installation method
The text was updated successfully, but these errors were encountered: