Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 299581 - calc build fails on ppc with incompatible types error
Summary: calc build fails on ppc with incompatible types error
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: calc
Version: rawhide
Hardware: powerpc
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Matthew Miller
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F-ExcludeArch-ppc
TreeView+ depends on / blocked
 
Reported: 2007-09-21 01:48 UTC by Matthew Miller
Modified: 2007-11-30 22:12 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-09-30 09:10:44 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)

Description Matthew Miller 2007-09-21 01:48:39 UTC 
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.
Comment 1 Denis Leroy 2007-09-21 11:22:56 UTC 
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.
Comment 2 Matthew Miller 2007-09-21 12:50:20 UTC 
Cool. Thanks everyone.
Comment 3 David Woodhouse 2007-09-30 09:10:44 UTC 
This is fixed now, right?
Comment 4 Matthew Miller 2007-09-30 11:03:56 UTC 
Yes; sorry -- I meant to close it with the comment above. Thanks again.
Note You need to log in before you can comment on or make changes to this bug.