I don't have a power pc system, but calc fails to build in the Fedora buildsys on ppc32 (builds fine on 64 bit) with this error: gcc -DCALC_SRC -DCUSTOM -Wall -W -Wno-comment -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -c -o file.o file.c file.c: In function 'filepos2z': file.c:1366: error: incompatible types in assignment make: *** [file.o] Error 1 The line in question is: SWAP_HALF_IN_FILEPOS(ret.v, &pos); and from fposval.h, #define SWAP_HALF_IN_FILEPOS(dest, src) memcpy((void *)(dest), (void *)(src), sizeof(FPOS_POS_BITS)) pos is a FILEPOS, which is typedef'd to fpos_t from <stdio.h>. ret is a "ZVALUE", defined in zmath.h, so ret.v is a *HALF, which is conditionally defined in zmath.h as either USB32 (unsigned long) or USB16 (unsigned short) depending on the value of HAVE_B64. Something is clearly going wrong in all of that.
The problem is fposval.h is automatically generated, and the code that generates it (fposval.c) is completely broken. It tries to detect the size of fpos_t, but fails. The best solution is to avoid it to use fgetpos() and fsetpos() at all (and use fseek() and ftell() instead, like most code nowadays), by adding this to the compile line: HAVE_FPOS="-DHAVE_NO_FPOS" \ However, the rpmbuild process on the system that David kindly gave me access to, fails at link time with some sort of architecture incompatiblity issue that I don't quite understand, not being very familiar with ppc. At least, it should help you move forward.
Cool. Thanks everyone.
This is fixed now, right?
Yes; sorry -- I meant to close it with the comment above. Thanks again.