c/ppc32 programming help wanted: calc ppc32 build bug

[Matthew Miller]

Since I don't have a ppc machine of my own, it's hard to track this down. I
kind of suspect something is wrong in the "longbits.h" code, but it could be
somewhere else entirely.

<https://bugzilla.redhat.com/show_bug.cgi?id=299581>


-- 
Matthew Miller           mattdm(a)mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>

[Kevin Fenzi]

On Thu, 20 Sep 2007 21:51:10 -0400
mattdm(a)mattdm.org (Matthew Miller) wrote:

>  Since I don't have a ppc machine of my own, it's hard to
> track this
>  down. I kind of suspect something is wrong in the "longbits.h" code,
>  but it could be somewhere else entirely.
>  
>  <https://bugzilla.redhat.com/show_bug.cgi?id=299581> 
Odd. Not sure whats going on there... 

I do however have a ppc32 machine. Email me a ssh key and I'd be happy
to give you access so you can try and track this down. 

kevin

[Eric Sandeen]

Matthew Miller wrote:
>  Since I don't have a ppc machine of my own, it's hard to
> track this down. I
>  kind of suspect something is wrong in the "longbits.h" code, but it could be
>  somewhere else entirely.
>  
>  <https://bugzilla.redhat.com/show_bug.cgi?id=299581>
>  
>   
Looking at the preprocessed source might help?  (gcc -E)

-Eric

[David Woodhouse]

On Thu, 2007-09-20 at 21:04 -0500, Eric Sandeen wrote:
>  Matthew Miller wrote:
>  > Since I don't have a ppc machine of my own, it's hard to track this down. I
>  > kind of suspect something is wrong in the "longbits.h" code, but it could
> be
>  > somewhere else entirely.
>  > 
>  > <https://bugzilla.redhat.com/show_bug.cgi?id=299581>
>  > 
>  > 
>  
>  Looking at the preprocessed source might help?  (gcc -E) 
No, it just makes your eyes bleed.

I have no idea what's going on here, or why it might have built on other
systems -- it looks horridly broken. It seems to be trying to treat the
fpos_t data type (which is an opaque structure and must be accessed with
fgetpos()) as if it was a scalar integer, along the lines of:

	unsigned long foo;
	fpos_t bar;
	foo = bar;

If that builds on i386, I have no clue why. And I also have no clue what
all this SWAP_HALF_IN_FOO() is all about, either.

I'll keep poking at it, for as long as I can stand before I have to kill
myself.

But first, let's start by fixing this unrelated (unless it was done
while smoking the same batch of crack) gem...

--- endian.c~	2007-09-01 23:01:25.000000000 +0100
+++ endian.c	2007-09-21 10:06:05.000000000 +0100
@@ -53,10 +53,8 @@ char byte[8] = { (char)0x12, (char)0x36,
 int
 main(void)
 {
-#if !defined(LITTLE_ENDIAN) && !defined(BIG_ENDIAN)
 	/* pointers into the byte order array */
 	int *intp = (int *)byte;
-#endif
 #if defined(DEBUG)
 	short *shortp = (short *)byte;
 	long *longp = (long *)byte;
@@ -76,11 +74,17 @@ main(void)
 	printf("#define BIG_ENDIAN\t4321\n");
 	printf("#define LITTLE_ENDIAN\t1234\n");
 
+	/* Yes. We _know_ they're the standard endian.h defines.
+	   They're both going to be defined.
+	   Always.
+	   So what, for the love of $DEITY, made anyone think 
+	   _this_ was a good idea....
 #if defined(LITTLE_ENDIAN)
 	printf("#define CALC_BYTE_ORDER\tLITTLE_ENDIAN\n");
 #elif defined(BIG_ENDIAN)
 	printf("#define CALC_BYTE_ORDER\tBIG_ENDIAN\n");
 #else
+	*/
 	/* Determine byte order */
 	if (intp[0] == 0x12364859) {
 	    /* Most Significant Byte first */
@@ -93,7 +97,7 @@ main(void)
 		"Unknown int Byte Order, set CALC_BYTE_ORDER in Makefile\n");
 	    exit(1);
 	}
-#endif
+//#endif
 	/* exit(0); */
 	return 0;
 }

-- 
dwmw2

[David Woodhouse]

On Fri, 2007-09-21 at 10:26 +0100, David Woodhouse wrote:
>  which is an opaque structure and must be accessed with fgetpos())
As the first cup of tea of the morning takes effect I realise that bit's
nonsense, but the rest seems still vaguely relevant -- it _is_ an opaque
type. I just don't know how to deal with it.

I hate userspace.

-- 
dwmw2

[Denis Leroy]

David Woodhouse wrote:
>  On Fri, 2007-09-21 at 10:26 +0100, David Woodhouse wrote:
> > which is an opaque structure and must be accessed with fgetpos())
>  
>  As the first cup of tea of the morning takes effect I realise that bit's
>  nonsense, but the rest seems still vaguely relevant -- it _is_ an opaque
>  type. I just don't know how to deal with it.
>  
>  I hate userspace. 
Just updated the bugzilla. It's trying to use fgetpos(),fsetpos() 
instead of fseek(),ftell(), but the code that tries to autodetect the 
size of fpos_t is broken.

Looks like the easiest solution is to force it to use fseek(), ftell() 
with -DHAVE_NO_FPOS.

The code compiles with this, but I still get a linking error at the end 
of rpmbuild:

collect2: ld terminated with signal 11 [Segmentation fault]
/usr/bin/ld: warning: powerpc:common64 architecture of input file 
`addop.o' is incompatible with powerpc:common output

[David Woodhouse]

On Fri, 2007-09-21 at 13:24 +0200, Denis Leroy wrote:
>  David Woodhouse wrote:
>  > On Fri, 2007-09-21 at 10:26 +0100, David Woodhouse wrote:
>  >> which is an opaque structure and must be accessed with fgetpos())
>  > 
>  > As the first cup of tea of the morning takes effect I realise that bit's
>  > nonsense, but the rest seems still vaguely relevant -- it _is_ an opaque
>  > type. I just don't know how to deal with it.
>  > 
>  > I hate userspace.
>  
>  Just updated the bugzilla. It's trying to use fgetpos(),fsetpos() 
>  instead of fseek(),ftell(), but the code that tries to autodetect the 
>  size of fpos_t is broken.
>  
>  Looks like the easiest solution is to force it to use fseek(), ftell() 
>  with -DHAVE_NO_FPOS.
>  
>  The code compiles with this, but I still get a linking error at the end 
>  of rpmbuild:
>  
>  collect2: ld terminated with signal 11 [Segmentation fault]
>  /usr/bin/ld: warning: powerpc:common64 architecture of input file 
>  `addop.o' is incompatible with powerpc:common output 
It works here. Use 'ppc make ppc' to build 32-bit packages from CVS, not
just 'make ppc'. Autocrap tends to get confused otherwise, and you end
up mixing 64-bit and 32-bit objects. Not that this really excuses a SEGV
from the linker -- can you show exactly what you did to provoke that?

-- 
dwmw2

[Denis Leroy]

David Woodhouse wrote:
>  On Fri, 2007-09-21 at 13:24 +0200, Denis Leroy wrote:
> > David Woodhouse wrote:
> >> On Fri, 2007-09-21 at 10:26 +0100, David Woodhouse wrote:
> >>> which is an opaque structure and must be accessed with fgetpos())
> >> As the first cup of tea of the morning takes effect I realise that bit's
> >> nonsense, but the rest seems still vaguely relevant -- it _is_ an opaque
> >> type. I just don't know how to deal with it.
> >>
> >> I hate userspace.
> > Just updated the bugzilla. It's trying to use fgetpos(),fsetpos() 
> > instead of fseek(),ftell(), but the code that tries to autodetect the 
> > size of fpos_t is broken.
> >
> > Looks like the easiest solution is to force it to use fseek(), ftell() 
> > with -DHAVE_NO_FPOS.
> >
> > The code compiles with this, but I still get a linking error at the end 
> > of rpmbuild:
> >
> > collect2: ld terminated with signal 11 [Segmentation fault]
> > /usr/bin/ld: warning: powerpc:common64 architecture of input file 
> > `addop.o' is incompatible with powerpc:common output
>  
>  It works here. Use 'ppc make ppc' to build 32-bit packages from CVS, not
>  just 'make ppc'. Autocrap tends to get confused otherwise, and you end
>  up mixing 64-bit and 32-bit objects. Not that this really excuses a SEGV
>  from the linker -- can you show exactly what you did to provoke that? 
I just did a rpmbuild -bb calc.spec, from the F-7 SRPM currently in CVS. 
The only change to the spec file os the -DHAVE_NO_FPOS above.