Hi Jay, On 02/22/2010 10:16 PM, Jay Sorg wrote: >> I did compiled xrdp (CVS version) on my hppa/PARISC Linux box (see: >> http://www.parisc-linux.org). >> When starting xrdp, it failed with: >> endian wrong, edit arch.h > > I'm glad this run time check worked and pointed you in the right direction.
Yes, a nice, small and very effective check :-) >> This error message is even correct, since PARISC is big-endian, >> while the source code was somehow miscompiled as little-endian. >> >> The following patch does fix xrdp for me on PARISC Linux. >> >> First, in arch.h, the autodetection of the endianess by the value >> of __BYTE_ORDER doesn't work, if __BYTE_ORDER hasn't been defined >> yet. My first part of the patch fixes this by #including<endian.h> >> on Linux architectures if __BYTE_ORDER wasn't defined yet. >> I assume this patch will fix other (big-endian) Linux builds too. > > There are 2 defines xrdp / parse.h need to compile properly. > One is either B_ENDIAN or L_ENDIAN need to be defined and also, > NEED_ALIGN needs to be defined on most non x86 machines. > The first part of your patch takes care of the endian but the align > still depends on __hppa__ being defined. I assume it is for you. > Up to this point, I've tried to not have any includes in arch.h. > Since we still use __hppa__ for align and __hppa__ is always big > endian, I just put it in the define for B_ENDIAN. Yes, that's fine as well. Thanks! > The best solution we will move to eventually, is the autotools can > detect both of these and define them in config.h. > Then, arch.h can include config.h. Yes, there are some more big endian architectures out there :-) Just a grep on Linux kernel gives some more candidates: [del...@xxxx linux-2.6]$ grep big_end arch/*/include/asm/byteorder.h arch/arm/include/asm/byteorder.h:#include <linux/byteorder/big_endian.h> arch/avr32/include/asm/byteorder.h:#include <linux/byteorder/big_endian.h> arch/frv/include/asm/byteorder.h:#include <linux/byteorder/big_endian.h> arch/h8300/include/asm/byteorder.h:#include <linux/byteorder/big_endian.h> arch/m32r/include/asm/byteorder.h:# include <linux/byteorder/big_endian.h> arch/m68k/include/asm/byteorder.h:#include <linux/byteorder/big_endian.h> arch/microblaze/include/asm/byteorder.h:#include <linux/byteorder/big_endian.h> arch/mips/include/asm/byteorder.h:#include <linux/byteorder/big_endian.h> arch/parisc/include/asm/byteorder.h:#include <linux/byteorder/big_endian.h> arch/powerpc/include/asm/byteorder.h:#include <linux/byteorder/big_endian.h> arch/s390/include/asm/byteorder.h:#include <linux/byteorder/big_endian.h> arch/sh/include/asm/byteorder.h:#include <linux/byteorder/big_endian.h> arch/sparc/include/asm/byteorder.h:#include <linux/byteorder/big_endian.h> arch/xtensa/include/asm/byteorder.h:#include <linux/byteorder/big_endian.h> (not all of them are _allways_ big endian. The necessary #defines are in the files) So, autodetecting the endianess is probably the best solution. >> The second part of my patch is a little more special. >> All Linux platforms/architectures normally have EAGAIN and >> EWOULDBLOCK error codes #defined to the same value. >> AFAIK, there is only one exception, which is PARISC-Linux. >> PARISC-Linux needs to keep compatibility to HP-UX, which has >> different values for EAGAIN and EWOULDBLOCK as well. >> The different values do break xrdp, since it was only testing for >> EWOULDBLOCK, although the Linux kernel on PARISC-Linux just returns >> EAGAIN instead. >> Testing for both return codes fixed this for me (and will for HP-UX as >> well). >> On platforms where EAGAIN and EWOULDBLOCK refer to the same value, >> the compiler will usually just optimize out the test for EAGAIN. > > NP, this is fine. > >> It would be nice, if you could apply this patch to CVS head. > > Thanks, I'm looking at the other patch too. Thanks! Helge ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ xrdp-devel mailing list xrdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xrdp-devel
