Bug#651452: illuminator: FTBFS on sparc (tsview-tsview.o: undefined reference to symbol 'lam_mpi_byte')

[Adam C Powell IV]

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 <hazelsct at 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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20111215/d67d68c4/attachment.pgp>