[Pkg-openmpi-maintainers] [Fwd: Bug#657625: FTBFS openmpi 1.5 (experimental) on armel]
jsquyres at cisco.com
Sat Jan 28 12:09:59 UTC 2012
I defer to ARM on this issue -- Leif?
On Jan 27, 2012, at 9:54 AM, Sylvestre Ledru wrote:
> Hello Jeff,
> Do you have any opinions on the options listed by Robie ?
> -------- Message transféré --------
> De: Robie Basak <robie.basak at canonical.com>
> Reply-to: Robie Basak <robie.basak at canonical.com>,
> 657625 at bugs.debian.org
> À: submit at bugs.debian.org
> Sujet: Bug#657625: FTBFS openmpi 1.5 (experimental) on armel
> Date: Fri, 27 Jan 2012 14:10:22 +0000
> 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]'
> 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. 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 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.
> : http://infocenter.arm.com/help/topic/com.arm.doc.dui0489c/CIHGHHIE.html
> : http://wiki.debian.org/ArmHardFloatPort
jsquyres at cisco.com
For corporate legal information go to:
More information about the Pkg-openmpi-maintainers