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

[Leif Lindholm]

Thanks Jeff,

Sylvestre:
I'm fine with the idea of Debian not building openmpi for (armv4t) armel. But would it be possible to include it in Ubuntu armel builds anyway?

Any armv4t implementation would be pretty inefficient - it would either
need a serialization point in form of a system call or to make use of
the SWP instruction. Plus, there is always LAM and MPICH for armv4t
users.

As for gcc-builtins - yes, they could be used, but there are other toolchain implications there:
- I'm not entirely sure when the 64-bit atomics were implemented for
  ARM, but they weren't available for the initial port.
- The gcc-builtins actually guarantee stronger ordering than is required
  by some of the open-mpi atomic operations (a potential performance
  issue).
- There still needs (?) to be standalone assembler implementations.

So in summary ...
1) I'm not fundamentally against it, but it's not a high enough priority
   for us to put the effort in ourselves.
2) Doesn't sound very nice.
3) Gets my vote.

Regards,

Leif

> -----Original Message-----
> From: Jeff Squyres [mailto:jsquyres at cisco.com]
> Sent: 28 January 2012 12:10
> To: Sylvestre Ledru; Leif Lindholm
> Cc: Pkg-openmpi-maintainers at lists.alioth.debian.org; Robie Basak
> Subject: Re: [Fwd: Bug#657625: FTBFS openmpi 1.5 (experimental) on
> armel]
>
> 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/
>


-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.