Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
---|---|---|---|---|---|---|
flavor-configure-option.patch | Add option --with-flavor=<flavor-name> to configure so that '_<flavor-name>' is appended to each built library, .e.g. libhdf5_<flavor-name>.so. This we can avoid library name collisions when installing both serial and $mpi flavors of the libraries: * serial is built with no flavor name * $mpi parallel versions use --with-flavor=$mpi =================================================================== |
Gilles Filippini <pini@debian.org> | no | |||
path_max.diff | avoid the issue of PATH_MAX not being available on Hurd. Call realpath() the POSIX way, with NULL as second parameter so that the returned string is dynamically allocated. This way there is no more need for the strdup() call. =================================================================== |
Gilles Filippini <pini@debian.org> | no | debian upstream | ||
ullong_force.diff | force the ullong conversion anywhere.=================================================================== | Sylvestre Ledru <sylvestre.ledru@scilab-enterprises.com> | no | |||
relax-version-check.patch | remove check on patch version hopefully changes in that number always are compatible. Without this every bugfix update would require a full transition as it will abort when the version does not match exactly. The version check will be executed with compile time values on every file access see e.g. H5F_ACC_RDONLY in src/H5Fpublic.h =================================================================== |
Julian Taylor <jtaylor@ubuntu.com> | no | debian | ||
fix-unaligned-accesses.patch | Hi, Currently libhdf5-100 performs unaligned memory accesses on sparc64 in certain cases, and this is causing the latest version of h5py to FTBFS due to the test suite being killed with SIGBUS when doing vlen-related tests (the tests in question being new in the latest upstream version). On investigating, there are two issues: 1. NO_ALIGNMENT_RESTRICTIONS is being defined on sparc64. GCC is sufficiently smart to notice that the test program run when configuring is performing unaligned accesses, and so instead of using the usual multi-byte load instructions (which require the address to be aligned), it expands it out into individual byte loads, and therefore the test actually succeeds. This is only because GCC can statically determine that the address is unaligned, and therefore tries to be helpful (since it knows using multi-byte loads will never work), whereas for a general address it will assume the address is aligned and emit a single multi-byte load. Adding in a few volatile qualifiers in the important places ensures that GCC can no longer statically prove the relevant addresses are unaligned, and therefore it uses the normal multi-byte load instructions and the test program will crash, so configure knows not to define NO_ALIGNMENT_RESTRICTIONS. 2. Even with that fixed, H5T_vlen_reclaim_recurse needs fixing to ensure it doesn't perform unaligned accesses when not supported. With the attached patch, h5py's test suite now passes again. Please feel free to forward this patch upstream if you deem it acceptable. Regards, James =================================================================== |
no | ||||
reproducibility.patch | =================================================================== | no | ||||
no-rpath.patch | drop rpath flags from h5cc et al commands See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023446#22 =================================================================== |
no | ||||
java-test-TestH5Arw_array-overflow.patch | Fix array overflow DIM_X=8 DIM128_Y=128 The dataset has 8x128 values, which matches the array's firt two dimensions. Each value is a 128 bit float. Because 128 bits = 16 bytes, the third dimension of the array should be 16. =================================================================== |
no | ||||
java_use-system-jars.patch | =================================================================== | no |