Package: openmpi
Version: 1.5.4-2~exp1
openmpi 1.5 fails to build on Debian armel:
/bin/bash ../../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I.
-I../../opal/include -I../../orte/include -I../../ompi/include
-I../../opal/mca/paffinity/hwloc/hwloc/include/private/autogen
-I../../opal/mca/paffinity/hwloc/hwloc/include/hwloc/autogen -I../..
-I/usr/include/infiniband -I/usr/include/infiniband -DNDEBUG -g -O2
-finline-functions -fno-strict-aliasing -c -o atomic-asm.lo atomic-asm.S
atomic-asm.S: Assembler messages:
atomic-asm.S:7: Error: selected processor does not support ARM mode `dmb'
atomic-asm.S:15: Error: selected processor does not support ARM mode `dmb'
atomic-asm.S:23: Error: selected processor does not support ARM mode `dmb'
atomic-asm.S:32: Error: selected processor does not support ARM mode `ldrex
r3,[r0]'
atomic-asm.S:35: Error: selected processor does not support ARM mode `strex
r12,r2,[r0]'
[etc]
The rest of this report is my understanding of the issue, in the hope
that this will help. I may be wrong, especially in my understanding of
Debian's side.
I've reproduced the FTBFS in a sid chroot, but I get a successful build
on Ubuntu precise, both armel and armhf.
So it seems that this is a toolchain issue - something to do with where
the Debian and Ubuntu toolchains differ.
I regret that I don't have as much low level knowledge as I'd like to
have, but I've been doing some research.
>From what I can find, the dmb/ldrex/strex etc. instructions only exist
in armv7[1]. And Debian appears to target armv4t. I think an
-march=armv7-a would fix it, and there also might be an assembly
directive to do this at source level rather than changing the build. But
on Debian that would break compability of this package for older
architectures, so I'm not sure if this would be acceptable for you.
I've also found that Debian targets armhf at armv7-a[2] so if I'm right
so far, perhaps an acceptable solution might be to drop armel support
for openmpi in Debian? As upstream are using armv7 instructions, I think
this would be reasonable.
I've been told that upstream have switched from gcc builtins to
dedicated armv7 code. So another option would be to conditionally use
gcc builtins again if < armv7.
So I think Debian's options are:
1) Extend upstream's armv7 support down to armv4t, perhaps by using
gcc builtins.
1b) Speak to upstream about (1). Perhaps this was unintentional and
they would be happy to use gcc builtins across the board?
2) Build this package for armv7-only somehow. I'm not sure if there's
a place for this sort of thing to go, or what Debian policy has to
say about this, since someone running armel on armv4t won't be able
to use openmpi then.
3) Drop armel support. I don't think this is such a bad option, since
AIUI openmpi users would generally be running servers on armhf (with
armv7 or higher) anyway.
[1]: http://infocenter.arm.com/help/topic/com.arm.doc.dui0489c/CIHGHHIE.html
[2]: http://wiki.debian.org/ArmHardFloatPort
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
