Failure on mips64el

[amckinstry]

We have a major problem at the moment in Debian on mips64el:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848574

Now its quite possible / likely this is a local toolchain issue, but my question: is openmpi 2.0.2 regression tested on mips64el ?
(Its ok on mips, mipsel and other 64-bit archs).

[jsquyres]

AFAIK we have no regresstion testing on MIPS at all. 😬

[ggouaillardet]

@PHHargrove is there any mips64el in your computer zoo ?

fwiw, computer zoo is defined at http://insidehpc.com/2012/11/silicon-darwinism-how-the-computer-zoo-is-charting-the-future-of-cpus/

[PHHargrove]

@ggouaillardet
Yes, I have both mips64 and mips64el and test thee ABIs (-mabi={32,n32,64}) on each.
All 6 passed my testing of 2.0.2rc4, which included running the ring examples (ring_{c,mpih,usempi,usempif08}) with two ranks on 1 node.
My tests are on Octeon II systems running Debian Wheezy, and are not mine to upgrade.

[amckinstry]

@jsquyres This appears to work fine with 2.0.2.
However Debian Stretch (9.0) is now in a freeze, and version 2.0.2 has a library version change, requiring a "transition" in Debian (rebuild of everything that uses openmpi, on all platforms).
Which won't happen.

So my best option at the moment is to do 2.0.2 without the change that required the version number bump (just the public interfaces / libraries, not the internal ones). IIRC the Fortran one at least was a trivial API change , but I can't find the ref anymore, can you point me to the changes please?

[hppritcha]

@amckinstry are you wanting changes between versions 2.0.1 and 2.0.2?

[amckinstry]

@hppritcha Yes
Just the changes that caused the version bumps, not all changes.
(I'm trying a git diff tag/2.0.1 tag/2.0.2 but it would help if someone knew)
.e.g. git diff 467ff3a 7dac5d3
bumps the MPI version but doesn't explain why it was bumped.

[jsquyres]

@amckinstry I'm not sure what you're asking.

Yes, we bumped libtool shared library versions in v2.0.2, but they're all in a backwards-compatible way. I.e., you shouldn't need to recompile applications/libraries dependent upon Open MPI (unless you have some policy that says so...?).

All the bumps in Libtool c values (from c:r:a) also bumped a, meaning that all the changes should be backwards compatible / not require any recompilation of apps or libraries.

Do you mean something else?

[amckinstry]

Apologies, you are correct. I was confusing major and minor version changes. I can use 2.0.2 as is.

I've uploaded 2.0.2 into Debian for the Stretch release.

[hppritcha]

Looks like #2280, #2541, #2752 should at least be considered.

[amckinstry]

@hppritcha Thanks. I'd checked out #2280 already, rebuilding everything in Debian (that uses opepenmpi) against it and it all built as-is.