[Pkg-openmpi-maintainers] [Fwd: Bug#657625: FTBFS openmpi 1.5 (experimental) on armel]

[Jeff Squyres]

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 ?
> 
> Thanks,
> Sylvestre
> 
> 
> -------- 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]'
> 
> [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
> 
> 
> 
> 
> 


-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/