summaryrefslogtreecommitdiffstats
path: root/bin/ltmain.sh
Commit message (Collapse)AuthorAgeFilesLines
* [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).