graphite2 also FTBFS on alpha and sparc64 at debian-ports. It appears to me that the common factor between the build failures (armel,sparc, sparc64,alpha) is that they are all RISC CPUs requiring strict alignment on memory accesses. I would bet on a misaligned memory access somewhere in the code, but not an actual issued misaligned access (as this will cause kernel traps on at least alpha and that does not occur) but one where the compiler thinks it should be aligned so issues an aligned memory access but ends up reading/writing the wrong thing. I've seen bugs like that before in code compiled on alpha, but it is no use reporting to the gcc developers as they will just point to the "undefined behaviour" bit of the standard and remind you that they are well within their rights to wipe your hard disc drive in such circumstances and one should be glad that they didn't.
Sparc is big-endian (IIRC) and the others little-endian so endianess is unlikely to be the cause. The graphite2 library code is instrumented at every step with checks on the read font. These are tripping out and just about every test fails because the font is failed to be read. I instrumented the code somewhat and found on armel that the first test "padauk1" in the test suite trips at Pass.cpp lines 200 and 201 in Pass::readRules(). In my test rc_begin had the value 0xb9740e which is greater than rc_end with the value 0xb97316. Ouch. When run on alpha the first test "padauk1" got a little bit further before it tripped at Code.cpp line 310 in Machine::Code::decoder::fetch_opcode() with 4 passed as both arguments to valid_upto() and as 4 is not less than 4 valid_upto() calls failure() to flag an "out_of_range_data" error in reading the font. Interestingly graphite2 compiles correctly and passes the test suite if I add the compiler flag -mcpu=ev67 to the build on alpha. In Debian we compile for generic alpha thus all byte/word accesses to memory are implemented as (aligned) longword (32bit)/quadword (64bit) accesses with the byte or word extracted from the longword/quadword with CPU register instructions. This enables Debian alpha to be run on all alphas. Specifying -mcpu=ev67 activates the byte-word extension, thus permits the compiler to issue actual byte or word memory accesses supported by only the more recent alpha hardware. A speculation: maybe some byte/word accesses are aliased and the compiler does not realise this, so optimises code to achieve a cock up if forced to access memory as longwords/quadwords as required on generic alpha. However, I am not sure if armel/sparc are so limited as alpha on byte/word accesses... I have not got any further than this in my investigations. Cheers Michael. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
