test failures in 4.0-beta14 and 4.0-beta15 #21
Comments
|
I think these are fixed on the development branch. It had to do with running multiple copies of bali-phy at the same time for the first time after it was compiled. Can you try out the current version on the I plan to release a beta-16 shortly, but if you could check that it work for you before I release it that would be helpful. |
|
Thanks for the bug report. I released 4.0-beta16. I believe this fixes the problem you found. |
|
4.0-beta16 does not have those test failures, but others. I did I've also attached the testlogs from the fresh build and the first rebuild. testlog-20241125-1335-fresh.txt |
|
On a Rocky9 system, running with |
|
Interesting... thanks for following up. The first set of errors seem to be because the python test harness is trying to print some program output that contains a unicode character (a bullet symbol), but the terminal says it doesn't support unicode. And indeed your environment variables include |
|
The second set of errors seem to relate to tests where bali-phy is supposed to fail and display a particular error message. I will look into this more... |
|
For the second set of errors, the directories This could be a bit tricky since the files contain ASCII escape sequences to show color, so the difference could show up as color difference. BTW, thanks again for this info. Since these don't occur on my Debian Linux system, or on the Ubuntu testers in github actions, I didn't know about these issues. |
|
The first set of errors, built and tested on a CentOS 7 system, shrinks after setting testlog-20241125-1517-centos7-haskell-math-RealFloat.txt The |
|
Thanks! I think I can fix the errors on Rocky Linux. I need to change the tests to that they don't depend on whether the terminal supports colors The math/RealFloat error is different -- it seems that somehow the C++ function |
|
This is being built with gcc/12.3.0 on both systems, and the return value depends on the value of the argument. From #ifndef __CORRECT_ISO_CPP11_MATH_H_PROTO_FP
constexpr bool
isnan(float __x)
{ return __builtin_isnan(__x); }
#if _GLIBCXX_HAVE_OBSOLETE_ISNAN \
&& !_GLIBCXX_NO_OBSOLETE_ISINF_ISNAN_DYNAMIC
using ::isnan;
#else
constexpr bool
isnan(double __x)
{ return __builtin_isnan(__x); }
#endif
constexpr bool
isnan(long double __x)
{ return __builtin_isnan(__x); }
#endif
#ifndef __CORRECT_ISO_CPP11_MATH_H_PROTO_INT
template<typename _Tp>
constexpr typename __gnu_cxx::__enable_if<__is_integer<_Tp>::__value,
bool>::__type
isnan(_Tp __x)
{ return false; }
#endifI did not initially understand this template correctly. It is supposed to always return the |
|
The problem is that glibc < 2.23 defines This problem would be fixed by using glibc version 2.23 or later, which was released in 2016 (eight years ago). Your cluster seems to have CentOS 7, which is really old, and reached its end-of-life in July 2024. Is there any chance you can upgrade to something that came out after 2016? Or, alternatively, use the singularity image? If not, I can add a workaround for CentOS 7. |
|
I think I've fixed the other test failures on the master branch by making the testing script more robust. You can download an updated tarball at I haven't been able to directly the unicode fixes because I haven't been able to find a terminal that doesn't support unicode yet. But I think it works. I'd be interested to hear if it works fine on your Rocky Linux box, and if the errors besides the math/Realfloat errors are fixed on Centos 7. |
|
The CentOS 7 portion of the cluster is hitting EOL at the end of the calendar year. The Rocky 9 build, I'll take a look in the next day or so with the new head and let you know. |
I'm seeing some test failures when building from source in 4.0-beta14 and 4.0-beta15. No errors building 4.0-beta13 from source. Same build system for all:
4.0-beta14
Meson output is
The failing tests are
4.0-beta15
Meson output is
and the failing tests are
The text was updated successfully, but these errors were encountered: