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
On Thu, 20 Sep 2007 21:51:10 -0400 mattdm@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.
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
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.
Looking at the preprocessed source might help? (gcc -E)
-Eric
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.
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; }
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.
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
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?
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.