Bugzilla Bug 133999

Between the new portage and other issues, the virtual/mpi situation is a little
bleak (as in neither mpich nor lam-mpi will build correctly in many cases). 
The new mpich2 ebuild has been reworked and should probably replace mpich after
a suitable period of testing.  This is just a reminder (mostly to me) to get
this version stablized on schedule to support other packages (eg, hdf5).  Other
arches like sparc may want to keyword and test as well...

1.0.3 tested on ppc64. it already has ~ppc64. will go stable in 30 days.

Should libmpich.so be built with -lrt to provide a NEEDED section for
librt.so.1 for undefined symbols aio_read64, etc.?  (x86 at least)

mpicc adds -lrt so build systems using this command will work fine but those
linking directly to libmpich may not.

compnerd: I'm pretty sure there is no one on x86 that could fully test this, so
when it is ready, could you please test it and mark it for us?

If I'm wrong and someone on the team can test it, please let me know :)

(^that last comment should have been nerdboy, but I'm an idiot)

nerdboy said he would handle this for x86, so I'm removing us.

Thanks :)

Added a ~sparc keyword.  Might slip us a little behind of the desired
stablization schedule.

Already ppc stable

stable on ppc64

Karl, would you like to expand a little on comment #2?  What's the issue on
amd64 vs. x86?  I only see references to Solaris needing librt...

I haven't looked into the source but just built mpich2-1.0.3 on x86.
(I haven't built on amd64.)

% ldd -r /usr/lib/libmpich.so
undefined symbol: aio_read64    (/usr/lib/libmpich.so)
undefined symbol: aio_error64   (/usr/lib/libmpich.so)
undefined symbol: aio_suspend64 (/usr/lib/libmpich.so)
undefined symbol: aio_write64   (/usr/lib/libmpich.so)
undefined symbol: aio_return64  (/usr/lib/libmpich.so)
        linux-gate.so.1 =>  (0xffffe000)
        libc.so.6 => /lib/libc.so.6 (0xafde4000)
        /lib/ld-linux.so.2 (0x7aaaa000)

I don't know how important this, but I was just concerned that some packages
might just link against libmpich without librt (if they didn't use mpicc) and
so would be missing these symbols.

If libmpich.so were built with -lrt there wouldn't be a problem as librt.so.1
would be pulled in through the NEEDED section of libmpich.so.

When using mpicc it fails with:

/usr/lib/libmpich.so: undefined reference to `MPIU_Free'
/usr/lib/libmpich.so: undefined reference to `MPIU_Malloc'

so i compiled mpich2-1.0.3 by hand and now it works. 

as `MPIU_Free' and `MPIU_Malloc' have been removed from mpich2 for the latest
versions i think a fix to the ebuilds is necessary

my system is x86

Looks like somebody forgot to remove us from CC after stabilizing this...

I cannot compile my programs on AMD64, because of:

/usr/lib64/libmpich.so: undefined reference to `MPIU_Free'
/usr/lib64/libmpich.so: undefined reference to `MPIU_Malloc'

Is there any chance that this will be fixed soon? I need MPI in order to be
able to work.

SPARC stable

The mpich2 ebuilds are being revamped by ribosome, so I'm closing this bug for
now.  Try the new ebuilds and post any new bugs (of course).  Openmpi is also
now available for testing.