The recent exchanges about the /usr/local/lib vs /usr/local/lib64 problem with libtool + autogen + guile gave me a critical clue. I examined all of the /usr/local/lib64/*.la files, and found dozens that mention (incorrectly) /usr/local/lib.
A couple of passes with "sed -i" scripts repaired them, and I was then able to build guile-1.8.8 successfully on GNU/Linux AMD64 with Red Hat 5.5, but there are still socket test failures on Red Hat 4.8 that may be a separate issue. There are still autogen-5.11.5 issues that I'm working on, but there is at least some progress. The problem seems to arise because libtool and autoconf have not dealt with the lib vs lib64 differences in a proper way. We got our first AMD64 boxes in July 2005, and both Red Hat and openSUSE provide a default 64-bit environment, with library directories that have lib64 as the final component. The companion lib directories hold the 32-bit libraries. On Solaris SPARC, there are is a default 32-bit world, and a less-commonly-used 64-bit one. I normally do builds on the AMD64 platforms with something like this (at a minimum): env LDFLAGS='-L/usr/local/lib64 -Wl,-rpath,/usr/local/lib64' ./configure make all check make install libdir=/usr/local/lib64 It does no good to specify libdir in the env of the configure run, because it does not propagate to the Makefile. It should not be necessary to put the libdir setting on the first make command, because configure is supposed to have created Makefiles and header files that are ready to build. The libdir setting on the second make is essential to prevent libraries from being copied into the lib directory, destroying possibly-existing 32-bit libraries. There seem to be a couple of solutions: (1) stopgap only: have the *.la files filtered by sed at installation time to create the correct -L and libdir settings. (2) redesign libtool to remove the undesirable and error-prone hardcoding of absolute paths in *.la files. Any path that appears in a .la file should be RELATIVE to the containing directory. The TeX Live tree uses that technique, as do the commercial Matlab, Maple, Mathematica, and SAS scripts, guaranteeing independence of the top-level directory location. I'm going to set up a daily cron job on our AMD64 systems to scan the installed *.la files for erroneous directory paths, because it is going to take a long time to sort out this problem by improved source-code packaging. Over the last five years, since the appearance of our book, Classic Shell Scripting, and its build-all software in Chapter 8, I have done well over 100,000 builds on 25+ flavors of Unix. Manual patching of *.la files at "make install" time is simply infeasible with that level of activity. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: be...@math.utah.edu - - 155 S 1400 E RM 233 be...@acm.org be...@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool