clone 651452 -1 reassign -1 src:petsc retitle -1 Rebuild with mpi-defaults >= 1.0 found -1 3.1.dfsg-11.1 block 651452 by -1 clone 651452 -2 reassign -2 src:suitesparse retitle -2 Rebuild with mpi-defaults >= 1.0 found -2 3.4.0-2 block -1 by -2 clone 651452 -3 reassign -3 src:spooles retitle -3 Rebuild with mpi-defaults >= 1.0 found -3 2.2-8 block -1 by -3 clone 651452 -4 reassign -4 src:hypre retitle -4 Rebuild with mpi-defaults >= 1.0 found -4 2.4.0b-7 block -1 by -4 clone 651452 -5 reassign -5 src:scotch retitle -5 Rebuild with mpi-defaults >= 1.0 found -5 5.1.11.dfsg-7 block -1 by -5 clone 651452 -6 reassign -6 src:blacs-mpi retitle -6 Rebuild with mpi-defaults >= 1.0 found -6 1.1-30.1 block -1 by -6 clone 651452 -7 reassign -7 src:scalapack retitle -7 Rebuild with mpi-defaults >= 1.0 found -7 1.8.0-7 block -1 by -7 clone 651452 -8 reassign -8 src:mumps retitle -8 Rebuild with mpi-defaults >= 1.0 found -8 4.9.2.dfsg-7 block -1 by -8 clone 651452 -9 reassign -9 src:mpi-defaults retitle -9 Get this out of testing until its rdepends have rebuilt found -9 1.0.1 block -9 by 651452 block -9 by -1 block -9 by -2 block -9 by -3 block -9 by -4 block -9 by -5 block -9 by -6 block -9 by -7 block -9 by -8 thanks
On Thu, 2011-12-15 at 14:36 -0500, Adam C Powell IV wrote:
> On Thu, 2011-12-15 at 09:55 +0100, Alexander Reichle-Schmehl wrote:
> > reopen 651452
> > found 651452 0.11.0-12
> > thanks
> >
> >
> > Hi!
> >
> > * Adam C Powell IV <hazel...@debian.org> [111214 15:33]:
> >
> > > Better to rip out the -llam and replace LLAM in the patch with -lmpi.
> > > I'll test then upload -12 with this change and let's see how it builds.
> >
> > That didn't work, too: It fails to build on armel, sparc due to that
> > precise error (tsview-tsview.o: undefined reference to symbol
> > 'lam_mpi_byte'). BTW: The build-depends in the sid chroot on
> > smetana.debian.org, the sparc porter box, are still available. And the
> > machine builds the package quite fast.
>
> Okay. I don't believe this is an illuminator error.
>
> The issue is that LAM should not be anywhere on the system, nothing
> should be linked with it, nothing should use its headers, nothing should
> try to link with it. The lam_mpi_byte symbol is probably a #define in
> the LAM headers, which shouldn't even be installed. libmpich2-dev has
> been the mpi-default-dev package on non-openmpi platforms for nearly
> seven months, so everything should have been rebuilt against it.
>
> So where is the LAM "contamination" coming from?
Found the problem. PETSc built on November 16 with mpi-defaults 0.6
which depended on LAM on non-openmpi arches. Now mpi-defaults 1.0.1
released 12/4 depends on MPICH2, so we have a mix of architectures
installed. And mpi-defaults just went into testing today... Crap!
It may be that other PETSc dependencies need rebuilding too... and there
are a lot of them! Let's see: suitesparse, spooles, hypre, scotch,
blacs-mpi, scalapack, mumps, all have to be rebuilt with MPICH2! What
was built when:
* suitesparse: April 15 2010
* spooles: May 11 2010
* hypre: August 15 2010
* scotch: April 6 2011
* blacs-mpi: August 29 2011
* scalapack: September 18 2011
* mumps: March 31 2011
None was built recently, all need to be rebuilt. mpi-defaults should
not be in testing until at least these are rebuilt, probably others.
Note: HDF5 is not a problem for PETSc because PETSc only links to it on
OpenMPI platforms. I forgot why that is, maybe it's worth a try
building PETSc against HDF5-mpich2? Maybe later...
Okay, cloning this bug to a bunch of packages, see above. I've been an
uploader to all except blacs-mpi and scalapack, and many of them could
use some maintenance, this is a good excuse to spend time on them. :-)
-Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Engineering consulting with open source tools
http://www.opennovation.com/
signature.asc
Description: This is a digitally signed message part
