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.
