Bugzilla Bug 118777

With either 1.6.2 or 1.6.4 version of hdf5, on sparc the build fails in
H5detect with a Bus error (probably inappropriately aligned FP data). (H5detect
seems to be a prebuild bootstrap program for something.) This is independent of
system (U60, US2 CPU), (SB1000, US3 CPU) and toolchain
(U60=sys-devel/gcc-3.3.5.20050130-r1 and friends, 2005.1;
SB1000=sys-devel/gcc-3.4.5 and friends, profile = 2006.0).  For completeness,
here is the emerge --info from the SB1000 system:
===========================================
Portage 2.1_pre3-r1 (default-linux/sparc/sparc64/2006.0, gcc-3.4.5,
glibc-2.3.5-r3, 2.6.13-rc3-vanilla sparc64)
=================================================================
System uname: 2.6.13-rc3-vanilla sparc64 sun4u
Gentoo Base System version 1.6.13
distcc 2.18.3 sparc-unknown-linux-gnu (protocols 1 and 2) (default port 3632)
[disabled]
ccache version 2.3 [disabled]
dev-lang/python:     2.3.5-r2, 2.4.2
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.20
virtual/os-headers:  2.4.26-r1
ACCEPT_KEYWORDS="sparc"
AUTOCLEAN="yes"
CBUILD="sparc-unknown-linux-gnu"
CFLAGS="-O2 -pipe -mcpu=ultrasparc3"
CHOST="sparc-unknown-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env
/usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env
/usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config
/usr/share/X11/xkb /usr/share/config /usr/spool/PBS /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d"
CXXFLAGS="-O2 -pipe -mcpu=ultrasparc3"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig cvs distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo
ftp://distro.ibiblio.org/pub/linux/distributions/gentoo/
http://gentoo.chem.wisc.edu/gentoo/
http://mirror.phy.olemiss.edu/mirror/gentoo"
LC_ALL="en_US.utf8"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="sparc X Xaw3d apache2 arts audiofile avi berkdb bitmap-fonts bzip2 crypt
cscope cups curl dlloader dri eds encode esd exif expat fam fbcon firebird
foomaticdb fortran gcc64 gd gdbm gif glut glx gmp gpm graphviz gstreamer gtk
gtk2 idn imagemagick imlib jpeg kerberos lcms ldap libwww lzw-tiff mad mhash
mikmod mng motif mpeg mysql ncurses nls nptl ogg oggvorbis openal opengl oss
pam pcre pdflib perl plotutils png python qt readline ruby ruby18 samba sdl
slang spell sqlite ssl stroke tcltk tcpd tetex tiff truetype truetype-fonts
type1-fonts udev vorbis xml xml2 xmms xv zlib elibc_glibc kernel_linux
userland_GNU"
Unset:  ASFLAGS, CTARGET, LANG, LDFLAGS, LINGUAS
=====================================================
This is a "hard" bug in that it is persistent, any system, any compiler &
toolchain.

Actually, the failure is in detect_C89_integers(void) when trying to do this:
DETECT_I(short,               SHORT,        d_g[nd_g]); nd_g++;
Apparently, this fails:
 ALIGNMENT(TYPE, INFO); 
where TYPE=short, INFO=d_g[2]
but further decoding the ALIGNMENT macro is beyond me right now.

Considered reporting this upstream, Ferris?

How's 1.6.5 on sparc?

Seems to do good, but if you build it without the static USE h5cc will still
keep looking for the static lib unless you use HDF5_USE_SHLIB=yes (thank Ferris
for finding out).
Should this be documented in some way?

Fixed by hdf5-1.6.5, adding ~sparc keyword and closing the bug.  NOTE:
1) FEATURES='test' USE='static' emerge hdf5
runs all tests and installs; h5cc works as expected.
2) FEATURES='test' USE='mpi' emerge hdf5
FAILS because lam-mpi will not run as root;
3) USE='mpi; emerge hdf5
works fine.
4) Please note Comment #4 --- if you do not build with USE=static, to use h5cc,
you must set HDF5_USE_SHLIB="yes".  This used to be documented in h5cc --help,
but no longer is.  However, it still seems to be the case. 

I have a version of the 1.6.5 ebuild that runs all the tests, including the mpi
tests (it runs mpd as portage; tested with mpich2 so far).  However, it still
uses the HDF5_Make_Ignore=yes flag to make it through the tests (one set of mpi
tests still fails, but all the MPIPOSIX and other tests complete successfully).

I still need to try another mpi package, as well as track down exactly what
causes the failure (I'm also having weird failures on the build of the mpich2
test drivers, but only 6 tests failed out of 373).  And those tests take a
while, even on a fast machine...