Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 281207 - Please stabilize =sys-cluster/mpi-dotnet-1.0.0
Summary: Please stabilize =sys-cluster/mpi-dotnet-1.0.0
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Matti Bickel (RETIRED)
URL:
Whiteboard:
Keywords: STABLEREQ
Depends on: 279573 299208 321039
Blocks:
  Show dependency tree
 
Reported: 2009-08-12 12:55 UTC by Matti Bickel (RETIRED)
Modified: 2012-12-25 12:35 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matti Bickel (RETIRED) gentoo-dev 2009-08-12 12:55:22 UTC
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.
Comment 1 Markus Meier gentoo-dev 2009-08-14 22:54:41 UTC
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.
Comment 2 Matti Bickel (RETIRED) gentoo-dev 2010-02-24 13:45:46 UTC
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
Comment 3 Matti Bickel (RETIRED) gentoo-dev 2010-02-24 13:46:42 UTC
See also the blocking bug
Comment 4 Matti Bickel (RETIRED) gentoo-dev 2010-02-28 21:12:28 UTC
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?
Comment 5 Justin Bronder (RETIRED) gentoo-dev 2010-02-28 22:00:04 UTC
(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.
Comment 6 Matti Bickel (RETIRED) gentoo-dev 2010-02-28 22:58:45 UTC
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.
Comment 7 Christian Faulhammer (RETIRED) gentoo-dev 2010-03-04 09:56:57 UTC
x86 stable
Comment 8 nixnut (RETIRED) gentoo-dev 2010-04-18 12:09:07 UTC
ppc stable
Comment 9 Pacho Ramos gentoo-dev 2010-06-18 18:22:42 UTC
Feel free to add us back when bug 321039 is solved. Thanks
Comment 10 Agostino Sarubbo gentoo-dev 2012-10-25 15:57:45 UTC
any progress here? good to go?
Comment 11 Matti Bickel (RETIRED) gentoo-dev 2012-12-25 12:35:44 UTC
Dropping stable request as upstream is inactive and the package will likely bitrot given the evolution of it's backend libraries. :/