summaryrefslogtreecommitdiffstats
path: root/bin/ltmain.sh
Commit message (Collapse)AuthorAgeFilesLines
* Update version for HDF5 1.10.9-2-rc1 release (#1784)Larry Knox2022-05-201-0/+11147
| | | | | | | | Update so numbers Update RELEASE.txt Update configure.ac for release: switch to production mode, disable maintainer mode Set HDF5_GENERATE_HEADERS to OFF in src/CMakeLists.txt Add files generated by autogen.sh for release.
* [svn-r26128] - Removed libtool generated/copied files.Dana Robinson2015-02-051-9655/+0
| | | | | | | | | | | - Modified autogen.sh to run libtoolize. NOTE: OS-X often uses glibtoolize. This will be fixed soon. - Addational helpful output added to autogen.sh. Part of HDFFV-9120 Tested on: 64-bit Linux VM
* [svn-r22706] Updated autotools: autoconf 2.69, automake 1.12.3, m4 1.4.16, ↵Larry Knox2012-08-221-38/+57
| | | | | | libtool 2.4.2 Tested THG machines.
* [svn-r19839] Updated to libtool v 2.4, autoconf 2.68 and m4-1.4.15.Larry Knox2010-11-231-728/+1619
| | | | Tested with h5committest on amani, heiwa, and jam.
* [svn-r19366] Updated autoconf to version 2.6.7, libtool to version 2.2.10, ↵Larry Knox2010-09-101-704/+1043
| | | | | | 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.
* [svn-r18579] Purpose:Mike McGreevy2010-04-151-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [svn-r15942] Purpose: Bug Fixes and Libtool UpgradeMike McGreevy2008-10-241-809/+1407
| | | | | | | | | | | | | | | | | | 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)
* [svn-r14933] Purpose: Updating HDF5 to use automake 1.10.1 and libtool 2.2.2Mike McGreevy2008-05-051-3307/+4252
| | | | | | | | | | | | | | | | | | 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)
* [svn-r13616] This check-in updates the bin/reconfigure file to point to the ↵Mike McGreevy2007-04-091-286/+651
| | | | | | | | 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.
* [svn-r12929] Hopefully this really is a fix for the tg-login errors.James Laird2006-11-161-651/+286
| | | | | | | | | | | 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.
* [svn-r12882] Changed bin/reconfigure to work on kagiso as well as on AFS ↵James Laird2006-11-081-286/+651
| | | | | | | | Linux machines. Updated to the latest versions of autotools. Tested on kagiso, heping, and juniper. Let me know if you have any problems.
* [svn-r10066] Purpose:James Laird2005-02-231-924/+2402
| | | | | | | | | | Libtool upgrade Description: HDF5 was using libtool 1.4.2. Upgraded to libtool 1.5.14. Platforms tested: verbena, heping, pommier, copper, modi4, arabica
* [svn-r10048] James Laird2005-02-201-1/+1
| | | | | | | | | | | | | | | | 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)
* [svn-r10016] James Laird2005-02-161-0/+3
| | | | | | | | | | | | | | | | | | | 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
* [svn-r5252] Purpose:Bill Wendling2002-04-251-85/+80
| | | | | | | | | | | 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
* [svn-r5246] Purpose:Bill Wendling2002-04-241-0/+2
| | | | | | | | | | | 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
* [svn-r5179] Purpose:Bill Wendling2002-04-121-2/+34
| | | | | | | | 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...
* [svn-r5132] Purpose:Bill Wendling2002-04-021-822/+1759
| | | | | | | | | | | | | | | | | | | 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
* [svn-r4987] Purpose:Bill Wendling2002-02-181-0/+5
| | | | | | | | | | | | | 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
* [svn-r4415] Bill Wendling2001-08-281-1/+1
| | | | | | | | | | | | | | | | 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
* [svn-r3857] Purpose:Bill Wendling2001-04-261-1/+1
| | | | | | | | | | | 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
* [svn-r3854] Purpose:Bill Wendling2001-04-241-1/+1
| | | | | | | | | | 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
* [svn-r3839] Purpose:Bill Wendling2001-04-241-1/+5
| | | | | | | | | | | 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
* [svn-r3838] Purpose:Bill Wendling2001-04-241-13/+4
| | | | | | | | | | | | | | | | | | | | | | (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...
* [svn-r3831] Purpose:Bill Wendling2001-04-221-2/+3
| | | | | | | | | | | 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
* [svn-r3829] Purpose:Bill Wendling2001-04-211-1/+23
| | | | | | | | | | | | 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
* [svn-r3772] Purpose:Bill Wendling2001-04-031-4/+8
| | | | | | | | | | | 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)
* [svn-r2507] Updated to most recent release of libtools (1.3.5). Most of the ↵Bill Wendling2000-09-051-1087/+2650
| | | | | | | | | | | | | | | | | | | | | | 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\"
* [svn-r1975] Purpose:Albert Cheng2000-02-181-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* [svn-r1651] Fold in J90 changesQuincey Koziol1999-09-241-1/+3
|
* [svn-r1112] Changes since 19990301Robb Matzke1999-03-021-0/+2453
---------------------- ./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).