Bug report: incompatible types in SWAP_HALF_IN_FILEPOS error cause build failure on S390x in 2.14.1.2

[mattdm]

Calc bug report template version: 1.3 2022-11-27

Describe the bug

While updating to the latest package, I ran into a build error on S390x. Specifically:

D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=z13 -mtune=z14 -fasynchronous-unwind-tables -fstack-clash-protection -Wno-error=long-long -Wno-long-long -c file.c
In file included from file.c:44:
file.c: In function 'filepos2z':
fposval.h:46:60: error: incompatible types when assigning to type 'HALF' {aka 'unsigned int'} from type 'FILEPOS' {aka 'fpos_t'}
   46 | #define SWAP_HALF_IN_FILEPOS(dest, src)         (*(dest) = *(src))
      |                                                            ^
file.c:1391:9: note: in expansion of macro 'SWAP_HALF_IN_FILEPOS'
 1391 |         SWAP_HALF_IN_FILEPOS(ret.v, &pos);
      |         ^~~~~~~~~~~~~~~~~~~~
make: *** [Makefile:2688: file.o] Error 1

Since SWAP_HALF_IN_FILEPOS was changed in this release, I assume this is new....

To Reproduce

Probably just "try to build on S390x". Certainly "try to build with the buildflags, etc., that Fedora uses".

Expected behavior

Build success

Attach debug.out

Not applicable, but see full build logs at:

https://koji.fedoraproject.org/koji/taskinfo?taskID=94836528

and specifically

https://kojipkgs.fedoraproject.org//work/tasks/6638/94836638/build.log

[lcn2]

Thank you very much for your clear bug report, @mattdm

We will make this a priority .. although right now we have a regional internet service outage .. this reply is being send thru a satellite phone ($$$-ive). Nevertheless we wanted to let you know that we will address this issue, work offline on the matter, and when our server is restored (in a few days is the ETA) we will get back to you.

[mattdm]

Since we dropped SPARC a long time ago and PPC (as opposed to PPC-LE) a while after that, s390x is our only big-endian architecture. So I'm not at all shocked to see portability bugs just there.

[lcn2]

The way filepos2z() and its counterpart that follows z2filepos() are being changed in calc version 2.14.2.0, due to an issue raised by a somewhat related issue #61 (how musl libc under gentoo uses fpos_t typed variables).

We plan to address this musl libc / fpos_t /filepos2z()&z2filepos()` next as part of our calc version 2.14.2.0 release.

It seems that the gcc compiler and the BigEndian architecture of s390x is good at detecting one of the mis-features of how the current calc does this. As such we plan to keep this issue open and make it a priority (along with the somewhat related issue #61) for the next version of calc.

Thanks in advance for helping us determine if our changes for alc version 2.14.2.0 will make this warning go away on the BigEndian architecture of s390x.

[sharkcz]

If access to a s390x system would be helpful, please let me know.

[lcn2]

If access to a s390x system would be helpful, please let me know.

It will certainly be helpful when the fix is ready to test.

[lcn2]

BTW: @sharkcz and @mattdm

We will be on a 2 month expedition and as such as will return to this matter in June 2023, FYI.

We have a general fix in mind, and once implemented, would be good to test in a s390x system.

[skriesch]

You can receive a Linux vm for free for 120 days on a mainframe via this link: https://developer.ibm.com/articles/get-started-with-ibm-linuxone/

If you want to receive long-term access as an Open Source Community Member, you can use this form with a reference to the special open source project: https://www.ibm.com/community/z/open-source/virtual-machines-request/

Choosable Linux distributions: SLES (upgradable to openSUSE), RHEL, Ubuntu, debian

[lcn2]

Thank you, we hope to address and access the VM in about 2 weeks.

[lcn2]

Hello @sharkcz and @mattdm,

Just a quick update:

We registered (using your 120-day 1st link) with IBM LinuxIONE, created a RHEL9.1 General purpose VM, and have ssh-ed into the server. We are in the process of setting up a calc repo and will test soon.

UPDATE 0

We have reproduced the problem you reported and will work on a general solution.

[lcn2]

With commit 3ec7b393669e041f2960db7012bc57f7c85f76e2 and the calc version 2.14.2.0 release, calc now compiles on a s390x IBM Mainframe running RHEL9.1.

[lcn2]

p.s. We have applied for a special open source project in order that we may be able to check that calc continues to compile and pass the regression test on the IBM mainframe.

[skriesch]

You can integrate also s390x as an architecture into Github Actions. You can use free VMs for development with the links above the same as mainframes for Github (in the same Cloud environment).

[lcn2]

You can integrate also s390x as an architecture into Github Actions. You can use free VMs for development with the links above the same as mainframes for Github (in the same Cloud environment).

Any advice or links to how this could be done would be appreciated.

[skriesch]

Initial issue for s390x Github Runners: https://github.com/actions/runner/issues/2263 Howto "how to run on different architectures" (IBM mainframe in the background): https://github.com/marketplace/actions/run-on-architecture