| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Tested with h5committest on amani, heiwa, and jam.
|
| |
|
|
|
|
| |
and m4 to version 1.4.14. Also added m4 directory for m4 macros according to autoconf suggestion.
Tested with h5committest on amani, jam, and heiwa, and on linew.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Autotool Upgrade / Libtool Bug Fix
Description:
Updated autotools referenced in bin/reconfigure as follows:
Autoconf 2.64 --> Autoconf 2.65
Automake 1.11 --> Automake 1.11.1
Libtool 2.2.6a --> Libtool 2.2.6b-mcg
The referenced libtool version is a custom version of 2.2.6b. It
has been tweaked to fix a bug in libtool that occurs
when using PGI 10.0 compilers. A check incorrectly categorizes
the C++ compiler as version 1.0 instead of 10.0, and the link
line is subsequently set up incorrectly and fails to compile.
A patch has been made available and will be included in the next
release of libtool, but in the meantime I've applied the patch to a custom
installation as indicated above. This bin/reconfigure now references
the custom installation, and the resulting configure script will correctly
categorize the PGI 10.0 C++ compiler.
Ran bin/reconfigure to regenerate configure and makefiles.
Tested:
jam and amani with PGI 10.0 compilers.
h5committest
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Description:
- Remove need to set LD_LIBRARY_PATH when using shared szip library.
- Libtool 2.2.6a is now used to generate libraries.
- 'make check install' dependency bug is fixed, and should no longer
break the build.
- removed hard coding of shell in config/commence.am, as this causes
problems on Solaris with the new version of libtool.
- RELEASE.txt with appropriate changes.
Tested:
- kagiso, smirom, linew (merged from 1.8, pretty quick tests)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Description: Applying update to autotools that was applied to 1.8 a couple
of weeks ago to the trunk.
Updated bin/reconfigure script to reflect the new versions of
libtool and automake in the /home1/packages/ directory.
Rearranged configure.in script. When using libtool 2.2.2, the
libtool script doesn't generate until later in the configuration
process, so I had to move a test that parsed through the libtool
script to a point after where it was actually being generated.
Ran libtoolize on the project, and ran bin/reconfigure to
regenerate configure and Makefile.in's throughout.
Tested: kagiso, smirom, linew (h5committest)
|
| |
|
|
|
|
|
|
| |
most recent versions of the autotools.
Updated autotool versions are: autoconf 2.61, automake 1.10.0, and libtool 1.5.22.
Tested on kagiso.
|
| |
|
|
|
|
|
|
|
|
|
| |
The version of libtool used by HDF5 isn't directly affected by the reconfigure
script; instead, libtoolize --force must be used by hand. Libtool was the
source of the problem, so rolling its version back to 1.5.14 should solve the
issue (at least temporarily).
Reconfigure should still work on both heping and kagiso.
Tested on heping, kagiso, and tg-login3.
|
| |
|
|
|
|
|
|
| |
Linux machines.
Updated to the latest versions of autotools.
Tested on kagiso, heping, and juniper. Let me know if you have any problems.
|
| |
|
|
|
|
|
|
|
|
| |
Libtool upgrade
Description:
HDF5 was using libtool 1.4.2. Upgraded to libtool 1.5.14.
Platforms tested:
verbena, heping, pommier, copper, modi4, arabica
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Purpose:
Bug fix
Description:
HDF5's libtool includes a hack to ensure that libraries are found
on IRIX. This hack did not have the correct path for the hl-fortran
tests to find the main library.
Solution:
Extend the hack. This may call for a better long-term solution...
Platforms tested:
modi4 (hack only takes effect on IRIX)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Purpose:
Bug fix
Description:
modi4 dies during build with strange errors.
The root cause of these is a two-year-old hack in HDF5's libtool
script that only takes effect on IRIX.
Solution:
Edited the libtool hack (by editing ltmain.sh) to correct a bug in
the hack.
Also made sure that compiler-specific DEFAULT_LIBS are used
when linking.
Platforms tested:
sleipnir, copper, modi4, sol
|
| |
|
|
|
|
|
|
|
|
|
| |
Update
Description:
Updated ltmain.sh with the newest version from the 1.4.2 libtool. The
one I updated with earlier still had a few bugs in it, for some
reason. I got rid of the RPM version on my machine and used the
compiled source instead.
Platforms tested:
Linux
|
| |
|
|
|
|
|
|
|
|
|
| |
Bug Fix
Description:
On some platforms, mktemp doesn't work. This would wipe out the
tmpdir variable's value.
Solution:
Reinitialize tmpdir in these cases.
Platforms tested:
HP-UX
|
| |
|
|
|
|
|
|
| |
Bug Fix
Description:
Ported the hack of hte ltmain.sh script from the v1.4 branch to the
1.5 branch, since it's sure to fail on systems with really long
-Wl... flags...
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Autotools Update
Description:
I've updated autoconf, automake, and libtool to the latest/greatest
versions; 2.53, 1.6, and 1.4.2 resp.
Many changes come with the new versions:
- ltconfig is no longer used
- acconfig.h is no longer used (#define values are declared with
the macro)
- regeneration of all of the aclocal.m4, configure, and
H5config.h.in files.
- new config.{guess,sub} files
- new ltmain.sh file
Platforms tested:
AIX (blue), and Linux
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Bug Fix
Description:
When doing an install of dynamic executables on some platforms, the
"mktemp" command may fail which causes the contents of "tmpdir" to go
away. If it's a failure, we still need the previous value of tmpdir.
Solution:
I replicated some code so that tmpdir's old value before the mktemp
call is regen'ed if the mktemp call failed.
Platforms tested:
HP-UX SysV
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Purpose:
Bug Fix
Description:
On some SGI machines (or, rather, it was showing up there), the
/usr/ncsa/lib directory was being placed before the other directories
in the linker line. This was causing the linker to link in
alternative HDF5 libraries than the test library.
Solution:
Modified my previous hack so that it puts the $rpath macro at the
end, since those are the ones we're passing into the libtool function
(in the DYNAMIC_DIRS macro).
Platforms tested:
Paz
|
| |
|
|
|
|
|
|
|
|
|
| |
Bug Fix
Description:
For parallel compiles, it needed the libtest.so library and wasn't
finding it.
Solution:
Added the path to the library to the rpath in the ltmain.sh file.
Platforms tested:
Modi4
|
| |
|
|
|
|
|
|
|
|
| |
Bug FIx
Description:
Fix to look in the src/.libs directory when in the tools directories.
Solution:
Added .libs to the rpath.
Platforms tested:
Linux
|
| |
|
|
|
|
|
|
|
|
|
| |
Bug Fix...
Description:
For the tools library, it needed to find the HDF5 library in the
`pwd`/../../src directory.
Solution:
Added `pwd`/../../src to the rpaths.
Platforms tested:
Modi4
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(Final?) Bug Fix
Description:
Okay, for those of you following this saga:
Shared libraries weren't being found on the O2K system. Why not?
Well, turns out that libtool is dain bramaged. Instead of
creating executables for executables, it creates shell scripts.
These shell scripts actually recompile the code, relinking it
with the "correct" libraries. It's similar to when it goes to do
an install. It recompiles to the binary so that it picks up the
proper libraries. BUT! Libtool wasn't placing into the shell
scripts where the shared libraries it was looking for actually
were.
Solution:
I hacked up ltmain.sh so that it puts the required dynamic library
directories into the compile line when it creates the
shell-script/binaries.
Platforms tested:
Modi4...
|
| |
|
|
|
|
|
|
|
|
|
| |
Bug Fix
Description:
The fix I put in on Friday wasn't working properly.
Solution:
Changed some single quotes to double quotes so that the macros are
expanded and set "command_finalize" to the newest values I created.
Platforms tested:
Modi4
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Bug Fix
Description:
The compiler on Modi4 (and possibly other machines) couldn't handle a
long string being passed in with the -Wl, flag.
Solution:
Wrote some script which separates the string being passed into
multiple flags with "-Wl,-rpath -Wl," before them.
Platforms tested:
Modi4
|
| |
|
|
|
|
|
|
|
|
|
| |
Update
Description:
Updated so that it's roughly consistent with the 1.3.5 release of
libtool. The only difference between the two is some sharedlibrary
path which Albert put in once a long time ago and it seems to
work...Trying not to break^Wfix what's not broken.
Platforms tested:
Linux (with diff)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
changes
applied for various platforms which weren't supported by libtools are now
standard for libtools it seems. There were only a few of the previous
fixes I rolled forward (the diffs follow):
config.sub:
750a760,763
> tflop*)
> basic_machine=i386-intel
> os=-osf1
> ;;
ltmain.sh:
2911c2911
< $shlibpath_var=\"$temp_rpath\$$shlibpath_var\"
---
> $shlibpath_var=\"$finalize_shlibpath$temp_rpath\$$shlibpath_var\"
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Configuration improvement
Problem:
Arabica has a zlib library that is a dynamic lib in /usr/ncsa/lib.
Binary generated would fail to run with a missig libz.so complain
if /usr/ncsa/lib is not in $LD_LIBRARY_PATH. This exposed the
problem that if the binary is linked with -L$mylibpath -lxyz
where libxyz is a dynamic type, the binary can't run if $mylibpath
is not in $LD_LIBRARY_PATH (or equivalent) or as part of the
system default library paths (e.g., /usr/lib, /usr/local/lib).
This problem also caused failures during configure (when trying
to see what format to print long long) and during H5detect.
The base cause is because libtool does not "transfer" the
knowledge of -L$mylibpath to the wrapper file its mode=link
generates.
Solution:
bin/ltmain.sh:
Changed it so that it transfers the libpaths from -Llibpaths
to the wrapper generated. I used the already defined variable
finalize_shlibpath. Not sure it is correct to use it this way.
Need to check on this.
configure.in:
Put in a patch to transfer information from LDFLAGS to LD_LIBRARY_PATH
right before the AC_TRY_RUN. The above fix for ltmain.sh does not
work here because libtool is generated later than this point.
There should be a cleaner way to do this.
Removed the hardcode of NCSA_LT_LINK_EXE because it is no longer
needed.
commence.in:
Removed the hardcode of NCSA_LT_LINK_EXE because it is no longer
needed.
Makefile.in:
Another patch of LDFLAGS to LD_LIBRARY_PATH because I could not
make it to generate H5detect in the wrapper form of libtool.
Need to make it to use the libtool correctly. Later.
Platform tested:
arabica (solaris 2.7)
baldric (solaris 2.6)
|
| | |
|
|
|
----------------------
./INSTALL
Reorganized and added some additional examples.
./MANIFEST
./aclocal.m4 [NEW]
./configure.in
./configure [REGENERATED]
./src/H5config.h.in [REGENERATED]
./bin/ltconfig [NEW]
./bin/ltmain.sh [NEW]
Added tests to determine how to compile shared libraries and
how to link programs with them before the libraries are
installed. Also how to install and uninstall shared
libraries. The configure step also prints the names of the
config files it's trying to load for easier debugging.
./bin/config.guess
./bin/config.sub
Replaced with a newer version from GNU. The changes we made
to that file to report `irix6.x' and `FreeBSD' without version
numbers have been incorporated into configure.in instead. In
the future, do not change these two files (see the top of
configure.in instead). By the way, this update was required to
get shared libraries working.
./config/linux [REMOVED]
./config/linux-gnulibc1 [NEW]
./config/linux-gnu [NEW]
./config/alpha-dec [REMOVED]
./config/alpha-dec-osf4.0 [REMOVED]
./config/dec-osf4.x [NEW]
./config/irix5.3 [REMOVED]
./config/irix5.x [NEW]
./config/irix64 [REMOVED]
./config/freebsd
Moved config files around to agree with output from the new
config.guess. The linux file was split into gnu (RedHat),
gnulibc1, and gnulibc2 versions. The alpha-dec file was
removed (I think it was unused) and the alpha-dec-osf4.0 was
changed to dec-osf4.x. The irix5.3 file renamed to irix5.x and
the irix64 file was renamed to irix6.x. The freebsd file was
changed to point to linux-gnulibc1. These changes were tested
on:
Linux 2.0
Linux 2.1
FreeBSD 3.2
Irix 5.3
Irix64 6.2
Irix64 6.4
HP/UX 10.20
OSF1 4.0
./config/alphaev56-dec-osf4.x
./config/irix64
Added warnings similar to linux/freebsd about using compilers
with known bugs.
./config/commence.in
./config/conclude.in
./src/Makefile.in
./test/Makefile.in
./testpar/Makefile.in
./tools/Makefile.in
Added definitions for shared libraries. This has been tested
on the following systems:
Linux 2.0
Linux 2.1
FreeBSD 3.2
Irix 5.3
Irix64 6.2
Irix64 6.4
HP/UX 10.20 static only
OSF1 4.0
If you want to disable use of shared libraries (you probably
do for development purposes since it takes a lot longer to
compile and because you have to run dynamically linked
programs in a special way if the library hasn't been
installed) then add `--disable-shared' to the configure
command line. This is all documented in the INSTALL file.
./bin/release
Temprarily commented out the MANIFEST checking when running
under svf since svf is about to be replaced by a newer
version. This change only affects error checking during the
release process.
./Makefile.dist
./Makefile.in
Added `make check' which does the same thing as `make _test'
since the former is endorsed by the GNU coding style and
people are used to it. The old `make _test' still works too
(and so does `make test' if you use GNU make).
|
