Has been working for me for the last month. I currently lack hardware to test for x86/amd64, so i hope someone can pick this up. If someone from ppc wants to test it - cool, another pair of eyes never hurt. If not, i'll mark it stable a week from now myself.
fails to build with sys-cluster/lam-mpi: >>> Install mpi-dotnet-1.0.0 into /var/tmp/portage/sys-cluster/mpi-dotnet-1.0.0/image/ category sys-cluster make -j1 DESTDIR=/var/tmp/portage/sys-cluster/mpi-dotnet-1.0.0/image/ install Making install in MPIUtils make[1]: Entering directory `/var/tmp/portage/sys-cluster/mpi-dotnet-1.0.0/work/mpi.net-1.0.0/MPIUtils' make[2]: Entering directory `/var/tmp/portage/sys-cluster/mpi-dotnet-1.0.0/work/mpi.net-1.0.0/MPIUtils' test -z "/usr/lib64" || /bin/mkdir -p "/var/tmp/portage/sys-cluster/mpi-dotnet-1.0.0/image//usr/lib64" /usr/bin/install -c 'MPIUtils.dll' '/var/tmp/portage/sys-cluster/mpi-dotnet-1.0.0/image//usr/lib64/MPIUtils.dll' make[2]: Nothing to be done for `install-data-am'. make[2]: Leaving directory `/var/tmp/portage/sys-cluster/mpi-dotnet-1.0.0/work/mpi.net-1.0.0/MPIUtils' make[1]: Leaving directory `/var/tmp/portage/sys-cluster/mpi-dotnet-1.0.0/work/mpi.net-1.0.0/MPIUtils' Making install in MPI make[1]: Entering directory `/var/tmp/portage/sys-cluster/mpi-dotnet-1.0.0/work/mpi.net-1.0.0/MPI' /usr/bin/gmcs -out:MPI.dll -unsafe -target:library -lib:../MPIUtils -reference:MPIUtils -optimize+ -define:BROKEN_IL_EMIT -define:BROKEN_NULL_DELEGATE -define:MPI_HANDLES_ARE_POINTERS -keyfile:./MPI.snk ./Attribute.cs ./CartesianCommunicator.cs ./Communicator.cs ./Comparison.cs ./DatatypeCache.cs ./Environment.cs ./Exceptions.cs ./GraphCommunicator.cs ./Group.cs ./Intercommunicator.cs ./Intracommunicator.cs ./Operation.cs ./Request.cs ./RequestList.cs ./Status.cs ./TagAllocator.cs ./TopologicalCommunicator.cs ./UnmanagedMemoryStream.cs CustomUnsafe.cs CustomUnsafe.cs(104,32): error CS1041: Identifier expected CustomUnsafe.cs(105,32): error CS1518: Expected `class', `delegate', `enum', `interface', or `struct' CustomUnsafe.cs(340,41): error CS0116: A namespace can only contain types and namespace declarations CustomUnsafe.cs(345,41): error CS0116: A namespace can only contain types and namespace declarations Compilation failed: 4 error(s), 0 warnings make[1]: *** [MPI.dll] Error 1 make[1]: Leaving directory `/var/tmp/portage/sys-cluster/mpi-dotnet-1.0.0/work/mpi.net-1.0.0/MPI' make: *** [install-recursive] Error 1 * * ERROR: sys-cluster/mpi-dotnet-1.0.0 failed. * Call stack: * ebuild.sh, line 49: Called src_install * environment, line 2779: Called die * The specific snippet of code: * emake DESTDIR="${D}" install || die "Install failed"; * The die message: * Install failed and sys-cluster/mpich2: configure: error: MPICH library is built statically. Please install MPICH built as a shared library by configuring MPICH with the --enable-sharedlibs=??? option) !!! Please attach the following file when seeking support: !!! /var/tmp/portage/sys-cluster/mpi-dotnet-1.0.0/work/mpi.net-1.0.0/config.log * * ERROR: sys-cluster/mpi-dotnet-1.0.0 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 2773: Called econf '--enable-shared' '--enable-static' * ebuild.sh, line 534: Called die * The specific snippet of code: * die "econf failed" * The die message: * econf failed but builds and runs w/o any problems with sys-cluster/openmpi.
Sorry for taking so long to respond. I will look into this, especially the MPICH2 failure. I only have one box to test on, so remerging mpi libs is painful for me. I will call arches back if I can verify a build on x86 (that's the only architecture I can test on, right now) with LAMP/MPICH2/open-mpi
See also the blocking bug
Hi Justin, just a quick question wrt mpich2 build failure. The configure.ac snippet in question is this: real_CC="$CC" CC="$MPICC" AC_CHECK_LIB(pmpich,MPI_Init,[HAVE_LIBPMPICH=yes],[HAVE_LIBPMPICH=no],) AC_CHECK_LIB(mpich,PMPI_Init,[HAVE_LIBMPICH=yes],[HAVE_LIBMPICH=no],) if test "$HAVE_LIBPMPICH" = "no" ; then if test "$HAVE_LIBMPICH" = "yes" ; then AC_MSG_ERROR([ MPICH library is built statically. Please install MPICH built as a shared library by configuring MPICH with the --enable-sharedlibs=??? option)]) fi fi It's testing for libpmpich*, which is not included in at least my copy of mpich-1.0.8. Thus, the test fails. I've no clue of mpich2, but i do recognize you pass --enable-sharedlibs=gcc and shared libs are available. I've also been unsuccessful in determining what libpmpich is good for. Can you clarify, so i can fix upstreams configure?
(In reply to comment #4) > Hi Justin, just a quick question wrt mpich2 build failure. The configure.ac > snippet in question is this: > > real_CC="$CC" > CC="$MPICC" > AC_CHECK_LIB(pmpich,MPI_Init,[HAVE_LIBPMPICH=yes],[HAVE_LIBPMPICH=no],) > AC_CHECK_LIB(mpich,PMPI_Init,[HAVE_LIBMPICH=yes],[HAVE_LIBMPICH=no],) > > if test "$HAVE_LIBPMPICH" = "no" ; then > if test "$HAVE_LIBMPICH" = "yes" ; then > AC_MSG_ERROR([ MPICH library is built statically. > Please install MPICH built as a shared library by configuring MPICH with > the --enable-sharedlibs=??? option)]) > fi > fi > > It's testing for libpmpich*, which is not included in at least my copy of > mpich-1.0.8. Thus, the test fails. I've no clue of mpich2, but i do recognize > you pass --enable-sharedlibs=gcc and shared libs are available. I've also been > unsuccessful in determining what libpmpich is good for. Can you clarify, so i > can fix upstreams configure? > It really shouldn't be testing for either. Both upstreams really only guarantee that the wrappers (mpicc and friends) will provide a stable interface. There is some work being done to get pkg-config file, but that probably won't hit the tree for a while.
Thanks justin for the input. Okay, i've restrained mpi-dotnet to openmpi and mpich2, the MPI implementations i can get mpi-dotnet to compile with. Build fixes do not require a rev-bump, so here we are again. Feel free to test and stable now or 30 days from now, at your discretion. Requesting keywords: sys-cluster/mpi-dotnet-1.0.0: amd64 ppc x86 @ppc: i don't own a ppc anymore and do not know of users on that arch. So feel free to drop the keyword entirely, if you wish.
x86 stable
ppc stable
Feel free to add us back when bug 321039 is solved. Thanks
any progress here? good to go?
Dropping stable request as upstream is inactive and the package will likely bitrot given the evolution of it's backend libraries. :/
