Re: How does one specify linking to 64 bit libraries when there is a choice?

[Nelson H. F. Beebe]

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: address@hidden  -
- 155 S 1400 E RM 233                       address@hidden  address@hidden -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------