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

[Alexander Reichle-Schmehl]

reopen 651452
retitle 651452 illuminator: FTBFS on archs where petsc uses liblam (tsview-tsview.o: undefined reference to symbol 'lam_mpi_byte')
found 651452 0.11.0-8.2
clone 651452 -1
retitle -1 illuminat: Build-Conflicts on libmpich2-dev to strict
thanks


Hi!

* Alexander Reichle-Schmehl <alexander at schmehl.info> [111212 13:45]:

> The problem seems to be, that petsc is linked to liblam on sparc, and
> therefore the additional linkerflad -llam is needed on that arch.  I
> have no idea, why this issue han't shown up on armel, mips, mipsel or
> s390, the other arches on which petsc uses lam.  My patch adds the
> missing flag on sparc.

And here we are again, this time on armel.  I have no idea, why
0.11.0-8.1 was build successfull on armel, as it seems to be the very
same isssue according to the build logs:
https://buildd.debian.org/status/logs.php?pkg=illuminator&arch=armel


The trivial workarround would be to extend the host arch query in
debian/rules similimar to the following:

DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH)

ifeq ($(DEB_HOST_ARCH), sparc)
	LLAM=-llam
else
ifeq ($(DEB_HOST_ARCH), armel)
	LLAM=-llam
else
	LLAM=
endif
endif

Note that I didn't test it, and as I have shown nicely in my NMU that
isn't very reliable.  So it might be better to check the lib itself,
e.g. with "objdump -x /usr/lib/libpetsc.so|grep -i liblam.so|grep NEEDED"

That shows the exptected line on sparc on armel, while it doesn't on
amd64, but I didn't to further checks.


> +  * Add libmpich2-dev to build-conflicts to prevent FTBFS as described in
> +    http://bugs.debian.org/651452#22 and #27)

Sorry, but that seems to have been a really bad idea, as not the
build-depends on armhf, mips, mipsel, s390 and s390x can't be fullfilled
at all.  I'm not sure if it would be better to drop that complelty (as
that seems to be a problem not showing up on the buildds) or make that a
arch-specific build-conflict (which would be cleaner solution, but the
list would need to be maintained).  I clone this bug, as this is a
different issue.


Best Regards,
  Alexander