Bug#684631: clisp doesn't build on armv7 hardware
x-debbugs-cc: debian-arm at lists.debian.org
clisp fails to build with a segfault in an armel sid chroot on my
beagleboard XM (armv7). It fails with an illegal instruction error if I
add armhf to the architecture lists, add -marm to the start (if I add it
after the existing "-falign-functions=4" it seems to get ignored it
looks like there may be a bug where only the first thing in cflags
actually gets used...) of cflags and try to build on an armhf system.
Both failures seem to be the same underlying issue. I don't know why it
ends up with a segfault on armel and an illegal intruction error on armhf.
There is a patch posted at
which fixes this. However the author of the patch claims the patch will
not work on v4, he is not clear whether when he says v4 he means only
plain v4 (which debian doesn't support) or whether he also includes v4t
(which debian does support) in that. Specifically he says
>After doing that, I again hit an illegal instruction, this time on a
line of this form:
>MOVEQS pc, lr
>That form of the instruction has been deprecated, and is apparently
now illegal on whatever Fedora's koji builders use. The new way to do
that is this:
>which the assembly language reference manual says is also friendlier
to the branch prediction logic. However, that instruction is not
available on ARM v4 and earlier. That >doesn't cause me any issues,
since Fedora only supports ARM v5 and later"
Can any arm assembler experts comment on whether this patch will break
things on armv4t (i'm pretty sure v4t has plain BX but I dunno about
BXEQ, a google search doesn't even seem to find anything relavent for
BXEQ) and if so whether there is a correct way to fix this issue that
will work for all hardware debian armel supports?
I've attatched a debdiff for the source i've been using to test things,
note that this is NOT in a fit state for upload right now, it needs some
cleanup, conditionalising (adding -marm on non arm architectures will
break things) and changelog work. Also note that despite the +rpi1 in
the version number this is not identical to what I plan to upload to
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...