"Regina Obe" <l...@pcorp.us> writes: >> On Thu, Jun 15, 2023 at 6:30 AM Greg Troxel <g...@lexort.com> wrote: >> >> > Looking at the logs (at end), overall this smells like either a >> > systematic issue where the floating point on my system is broken, or >> > there is some slight floating point difference from x86, and geos >> > tests are very sensitive to exact FP results. But that's just guessing. >> >> In terms of CI, it's linux/windows/macos all on Intel. In terms of >> development, >> there's me on MacOS AppleSilicon, so getting a little >> Arm64 in there. It's possible there's something special about the floating >> point >> in the RPI3, but there's also a failure in unit-io-GeoJSONReader in there, >> which >> ... is not doing any heavy lifting. So I duno. As with other fun platforms >> I'm >> always open to patches. :) > > We do have 2 rasberry Pis (Arm64 and Arm32) running debian bullseye testing - > berrie and berrie64 > And those look to be showing successes. But not sure about the endian. > > https://libgeos.org/project/development/ci_status/
Interesting. Raspberry Pi culture is very much to run LE, and I have never heard of Debian doing BE on RPI. NetBSD people do occasionally, just to be difficult, I mean to help with testing. > I think we've had issues in past specific to big endian. I would expect so absent testing. Someday(tm) I will have an emulated sparc64 to run tests on. For now, I think the project should just keep my report in mind in case there are similar, but I don't think it's reasonable to ask anyone to do anything, mostly. My only suggestion for the CI page is: Avoid using '32-bit' and '64-bit' as if that describes a CPU type, using i386/x86_64 for PCs and armv7/aarch64 (or some such) for RPI/ARM. but that's just being picky about wording, not anything real. _______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
