nczarr_test_run_ut_mapapi fails on s390x (big-endian)

[hjaekel]

nczarr_test_run_ut_mapapi fails on alpine linux edge s390x for version 4.8.0

*** Test zmap read/write data -k file
canonicalfile: /builds/hjaekel/aports/community/netcdf/src/netcdf-c-4.8.0/nczarr_test/tmp_mapapi.file
url=|file:///builds/hjaekel/aports/community/netcdf/src/netcdf-c-4.8.0/nczarr_test/tmp_mapapi.file#mode=nczarr,file|
testing: simpledata:
Pass: open
Pass: /data1: write
Pass: close
Pass: re-open
Pass: /data1:exists
Pass: /data1: len
Pass: /data1: read
Pass: /data1: content verify
Default type: ubyte
Default action: objdump
--- /builds/hjaekel/aports/community/netcdf/src/netcdf-c-4.8.0/nczarr_test/ref_ut_mapapi_data.cdl
+++ ./ut_mapapi_data_file.cdl
@@ -2,7 +2,7 @@
 "foo": 42,
 "bar": "apples",
 "baz": [1, 2, 3, 4]}|
-[1] /data1 : (100) (ubyte) |0, 0, 0, 0, 1, 0, 0, 0, 2, 0, 0, 0, 3, 0, 0, 0, 4, 0, 0, 0, 5, 0, 0, 0, 6, 0, 0, 0, 7, 0, 0, 0, 8, 0, 0, 0, 9, 0, 0, 0, 10, 0, 0, 0, 11, 0, 0, 0, 12, 0, 0, 0, 13, 0, 0, 0, 14, 0, 0, 0, 15, 0, 0, 0, 16, 0, 0, 0, 17, 0, 0, 0, 18, 0, 0, 0, 19, 0, 0, 0, 20, 0, 0, 0, 21, 0, 0, 0, 22, 0, 0, 0, 23, 0, 0, 0, 24, 0, 0, 0|
+[1] /data1 : (100) (ubyte) |0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 2, 0, 0, 0, 3, 0, 0, 0, 4, 0, 0, 0, 5, 0, 0, 0, 6, 0, 0, 0, 7, 0, 0, 0, 8, 0, 0, 0, 9, 0, 0, 0, 10, 0, 0, 0, 11, 0, 0, 0, 12, 0, 0, 0, 13, 0, 0, 0, 14, 0, 0, 0, 15, 0, 0, 0, 16, 0, 0, 0, 17, 0, 0, 0, 18, 0, 0, 0, 19, 0, 0, 0, 20, 0, 0, 0, 21, 0, 0, 0, 22, 0, 0, 0, 23, 0, 0, 0, 24|
 [3] /meta1/.zarray : (34) |{
 "shape": [1,2,3],
 "dtype": "<1"}|
<end of output>
Test time =   0.03 sec
----------------------------------------------------------
Test Failed.
"nczarr_test_run_ut_mapapi" end time: Apr 17 20:48 UTC
"nczarr_test_run_ut_mapapi" time elapsed: 00:00:00
----------------------------------------------------------

[DennisHeimbigner]

If I recall, the s389x is big-endian. We have had difficulty testing on big-endian
machines, so I expect this is a big-endian problem.

[hjaekel]

Yes, s390x is big-endian. Can you say if this is just an issue in the test suite (which means I can just ignore this test on s390x and upgrade the package in Alpine) or the library writes data in the wrong way on big-endian machines (which would require a fix in the library)?

[DennisHeimbigner]

I believe it is a problem with the library. As I indicated,
it is difficult for us to test on big-endian machines, so
errors slip through. I believe I now have access to a big-endian
machine on which to test. So a fix is possible.