Re: system libraries that need -R/path/

[Bruno Haible]

Akim Demaille and I suggested earlier to move autoconf-lib-link to autoconf.

Gary V. Vaughan suggests moving them to libtool instead.

Actually this small package consists of three things:

  A) The autoconf macros and their associated documentation.
  B) The config.rpath file which contains the platform dependencies.
  C) A testsuite that tests the combination of (A), (B), and libtool.

(A) fits best into autoconf, because
  1. The autoconf-lib-link macros are primarily made for linking with
     _any_ kind of shared or static library. libtool libraries (.la) are
     supported as a special case, with special benefits.
  2. This is where users look for it, as Harlan Stenn pointed out.
  3. The documentation of the macros fits in 50 lines. If you were to put
     it into libtool's documentation, with its complexities of versioning,
     dlopening, --mode switches, etc. etc., users would get lost.

(B) doesn't fit into autoconf, because autoconf is not meant to install
files in AUX_DIR - that's automake's job. It can also fit in libtool
because the values that config.rpath outputs are a subset of those used
by libtool.

(C), the testsuite, fits best into libtool because it's libtool which
is the most fragile - due to its complexity - and therefore the most
likely to break the combination of (A) + (B) + libtool on particular
platforms. Put another way: The macros (A) change rarely in ways that
would make them break on particular platforms; therefore simple testing
is sufficient for them. However libtool needs more thorough testing
because it has the biggest wealth of platform dependent parameters
(hardcode_libdir_spec etc.)

So my proposal is:

   * Move (A) to autoconf,
   * Move (B) to be maintained by the libtool people, but distribute
     it through automake (like automake also distributes 'mkinstalldirs',
     'ylwrap', 'elisp-comp' etc.), Alternatively, distribute it through
     the same channel as config.guess and config.sub, namely either a
     regular update on ftp.gnu.org or a reference to the savannah-hosted
     CVS.
   * Move (C) to libtool.


Gary wrote:

> The problem with maintaining them in autoconf is that they will always be a
> step behind the equivalent code in libtool, and neither would get the others
> bug fixes reliably.

If you want speedy releases, then distribute config.rpath like
config.guess and config.sub. For my part, I think it's OK for a package
to distribute a slightly out-of-date config.rpath, because those few
people who need the adaptations for the newest platforms can simply
download and replace this single file. The situation is not like libtool.m4,
which - once replaced with a newer version - requires runs of autoconf,
autoheader etc. in order to be functional.

In the past, I have updated config.rpath _reliably_ from libtool releases.
In the other direction (config.rpath -> libtool) there were communication
problems that looked like being due to the structure, size or motivation
of the libtool team; I can't tell exactly.


Bruno