[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Bug in kwm/gradientFill.C
From:       Stephan Kulow <coolo () caldera ! de>
Date:       1999-08-20 7:41:17
[Download RAW message or body]

Harri Porten wrote:
> 
> Kurt Granroth wrote:
> > 
> > I just downloaded the 1.1.2pre snapshots to try my hand at compiling them
> > on Solaris 2.5.1.  Things were going swell until it got to
> > kwm/gradientFill.C and I received the following error:
> > 
> > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/home/kurt/opt/kde/include \
> > -I/home/kurt/opt/qt/include  -I/usr/openwin/include    -O2 -Wall -c \
> > gradientFill.C gradientFill.C:8: endian.h: No such file or directory
> > gmake[1]: *** [gradientFill.o] Error 1
> 
> Gooood that we discovered this in time. The "endian.h" is coming from a
> submitted patch fixing the gradients for PPC.
> 
> > Oops!  I peeked around a bit and couldn't find an endian.h *anywhere* on my
> > system.  Since it looks like all that does in supply BYTE_ORDER and the
> > BIG_ENDIAN/LITTLE_ENDIAN globals, I searched for those too.  No such luck.
> > 
> > However, this *is* a file /usr/include/sys/isa_defs.h that defines some
> > processor specific stuff based on which processor is running.  It doesn't
> > have a BYTE_ORDER.. but it *will* #define _BIG_ENDIAN or #define
> > _LITTLE_ENDIAN based on the processor...
> 
> Is there any portable way to define the endianess ? Otherwise I'll write
> a configure test checking for endian.h. If it's not there we would use
> big endian as default.

QImage::systemB{it,yte}Order sounds good to me

Greetings, Stephan

-- 
Better give your hours some more life than
your life some more hours. - anonymous


[prev in list] [next in list] [prev in thread] [next in thread]