Bug#657625: FTBFS openmpi 1.5 (experimental) on armel

2012-02-26 Thread Ron Broberg 
I'm not sure if this information is directly related to this report,
but using hints contained in the original report,
I was able to compile the upstream openmpi-1.5.4 distribution on a Debian6 
armv6l qemu emulation.
http://www.open-mpi.org/software/ompi/v1.4/downloads/openmpi-1.4.5.tar.bz2


You have to make 3 changes to the package
 1) Delete all references to the RISC instruction 'dmb'
 2) Modify the 'configure' file to include an 'armv6' option
 3) Compile with CFLAGS=-march=armv6 

## 1) make the following edits to these three files
./opal/asm/generated/atomic-local.s
delete all dmb instructions
./opal/asm/base/ARM.asm
delete all dmb instructions
./opal/include/opal/sys/arm/atomic.h
change the lines:
#if OPAL_WANT_SMP_LOCKS
#define MB()  __asm__ __volatile__ (dmb : : : memory)
#define RMB() __asm__ __volatile__ (dmb : : : memory)
#define WMB() __asm__ __volatile__ (dmb : : : memory)
#else
#define MB()
#define RMB()
#define WMB()
#endif

to read:
#define MB()
#define RMB()
#define WMB()

## 2) add the following to the 'configure' file at line 26946 of 171183
goto line 26946, there should be an 'alpha-' section above and an 'armv7' below
insert the following
        armv6*)
            ompi_cv_asm_arch=ARM
            OPAL_ASM_SUPPORT_64BIT=0
            OMPI_GCC_INLINE_ASSIGN='mov %0, #0 : =r(ret)'
            ;;

## 3) compile and install with the following CFLAGS
CFLAGS=-march=armv6
./configure CFLAGS=-march=armv6
make
sudo make install

more information about my build at
http://rhinohide.wordpress.com/2012/02/26/openmpi-on-raspberry-pi/



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#657625: FTBFS openmpi 1.5 (experimental) on armel

2012-01-27 Thread Robie Basak 
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