Helpers_TEST fails on arm64 debbuilds

[scpeters]

Environment

• OS Version: Ubuntu 18.04, 20.04, 22.04, debian Buster
• Source or binary build? debbuild for arm64 architecture

Description

• Expected behavior: test passes (as it does on other architectures)
• Actual behavior: test fails

[ RUN      ] HelpersTest.AppendToStream
/home/jenkins/workspace/ign-math6-debbuilder/build/ignition-math-6.12.0/src/Helpers_TEST.cc:1012: Failure
Expected equality of these values:
  out.str()
    Which is: "0 456 0 3.14159 3.141592654 3.141592653589793238462643383279503"
  "0 456 0 3.14159 3.141592654 3.141592653589793239"
/home/jenkins/workspace/ign-math6-debbuilder/build/ignition-math-6.12.0/src/Helpers_TEST.cc:1022: Failure
Expected equality of these values:
  out.str()
    Which is: "0 456 0 3.14159 3.141592654 3.141592653589793238462643383279503 3.14"
  "0 456 0 3.14159 3.141592654 3.141592653589793239 3.14"
[  FAILED  ] HelpersTest.AppendToStream (0 ms)

Steps to reproduce

1. Rebuild the following jobs

• https://build.osrfoundation.org/job/ign-math6-debbuilder/1418/
• https://build.osrfoundation.org/job/ign-math6-debbuilder/1420/
• https://build.osrfoundation.org/job/ign-math6-debbuilder/1424/
• https://build.osrfoundation.org/job/ign-math6-debbuilder/1427/

Output

[j-rivero]

This one is new to me. Somehow arm64 is rounding up the precision for PI while the other arches are not doing it. Not sure the severity of the issue since it is affecting what seems to an str method. If the problem of the lost of precision is affecting only string representation we could potentially ignore the error if the tests if we consider it superficial, if the problem is deep in the number real value then should be fixed.

[j-rivero]

Going to leave the issue open, see #510 (comment)