Bug Fix/Code Cleanup/Doc Cleanup/Optimization/Branch Sync :-)
Description:
Generally speaking, this is the "signed->unsigned" change to selections.
However, in the process of merging code back, things got stickier and stickier
until I ended up doing a big "sync the two branches up" operation. So... I
brought back all the "infrastructure" fixes from the development branch to the
release branch (which I think were actually making some improvement in
performance) as well as fixed several bugs which had been fixed in one branch,
but not the other.
I've also tagged the repository before making this checkin with the label
"before_signed_unsigned_changes".
Platforms tested:
FreeBSD 4.10 (sleipnir) w/parallel & fphdf5
FreeBSD 4.10 (sleipnir) w/threadsafe
FreeBSD 4.10 (sleipnir) w/backward compatibility
Solaris 2.7 (arabica) w/"purify options"
Solaris 2.8 (sol) w/FORTRAN & C++
AIX 5.x (copper) w/parallel & FORTRAN
IRIX64 6.5 (modi4) w/FORTRAN
Linux 2.4 (heping) w/FORTRAN & C++
Misc. update:
bug fix
Description:
added a condition that checks if the hl library is enabled to add it to the list of linking libraries
Solution:
Platforms tested:
linux
Misc. update:
modified h5cc to link with the high level library (libhdf5_hl)
Description:
added libhdf5_hl.a to the list of libarries to link with
Solution:
Platforms tested:
linux
Misc. update:
Feature
Description:
Added option -showconfig which Shows the HDF5 library configuration summary
Platforms tested:
No h5committest test which does not test these tools.
Tested in eirene by hand.
Misc. update:
Purpose:
Bug Fix
Description:
The flags for the linker on MacOS X were invalid.
Solution:
If this is a darwin platform (MacOS X), then don't specify the
runtime linker flags.
Platforms tested:
MacOSX (since it only affects it...)
Misc. update:
Bug Fix
Description:
The order the libraries are included in the compilation line is very
important.
Solution:
Need to specify the libraries in the order that they are given. If
we're building the application staticly, then use the static HDF5
library.
Platforms tested:
Modi4
Verbena
Arabica
Misc. update:
Bug Fix
Description:
Two things:
- static libraries may depend upon the HDF5 library. We should
put them before the HDF5 library on the commandline instead of
afterwards to avoid conflict.
- the CFLAGS weren't being used during linking. This was causing
problems on Arabica where the flags are important to
distinguish between building a 32-bit and 64-bit application.
Solution:
- Added logic so that it catches the static libraries and puts them
before the hdf5 library on the command line. WARNING: This may not
work in all situations...but it should be okay for the good
majority.
- added the CFLAGS macro to the commandline...
Platforms tested:
LInux (Colonelk)
Arabica
Modi4 (Parallel)
(Small changes so doesn't need full h5committesting...)
Misc. update:
Bug Fix
Description:
Lots of things. Mostly, multiple libraries declared on the command
line bothered some compilers. Then the order of the libraries is
important. Then if you are building static, you don't want an
"-lhdf5" flag in your compile line.
Solution:
Various hacks to remove redundant libraries from the compile line and
to keep the order of them and to replace -lhdf5 with the .a file when
building static.
Platforms tested:
Modi4 (Fortran & Parallel)
Verbena (Fortran & C++)
Arabica (Fortran)
Misc. update:
Fix
Description:
The way I was checking for -lfoo flags wasn't rigorous enough.
Solution:
Use a "grep" instead of the "case" statement. Also check that the
full "-lfoo" flag is matched instead of just part of it.
Platforms tested:
Linux (small fix)
Misc. update:
Bug Fix
Description:
Some compilers aren't happy if you specify the same library multiple
times when linking. This caused HDF5 Lite to crash during tests on
Kelgia
Solution:
Modified the script so that the shared libraries are specified only
once for the commandline.
Platforms tested:
Kelgia (small fix).
Misc. update:
Bug Fix
Description:
When doing a "configure" using the h5cc script as the compiler, it
would fail to accept the "-E" flag as running the preprocessor. The
problem was that it was trying to link the file afterwards. Of
course, the file wouldn't be there, so it would fail.
Solution:
Changed it so that if the -E flag is used, then we don't try to link
(this is how it's done in mpicc...I must have copied it wrongly).
Platforms tested:
Linux & Kelgia (small change not needing full testing)
Misc. update:
Possible Bug Fix
Description:
There seems to be a problem with the h5cc script picking up old
header files. This may have something to do with the CPPFLAGS macro
being set to some nefarious thing and the compiler looking in those
directories for the header files instead of the one where HDF5 is
actually installed.
Solution:
Put the -I$includedir first.
Platforms tested:
None...This is really triggered by the nightly tests. I'm kind of
hoping that this will fix things...
Bug Fix
Description:
Some -I paths weren't included in the h5cc script. That would cause
the compiler to fail if it was trying to find gass header files or
the like.
Solution:
Added the CPPFLAGS macro to the h5cc.in file so that it'll be there
when it's generated. This will also include some -D options which we
compiled the library with, like the LFS flags on Linux.
Also changed the configure* files so that it will "chmod" the created
h5cc file to 755 (executable) since that wasn't happening all the
time...
Platforms tested:
Linux
Bug Fix
Description:
The library path was relying upon the "exec_prefix" variable.
However, we weren't including that into the h5cc script.
Solution:
Added it.
Platforms tested:
Linux
