Re: gettext 0.10.40 build problem of tar-1.13.25 on Yellow Dog GNU/Linux

[Paul Eggert]

> From: Bruno Haible <address@hidden>
> Date: Fri, 26 Oct 2001 23:56:54 +0200 (CEST)
> 
> Here is a second patch. It consists of adding AM_PROG_LIBTOOL to
> configure.ac

Your first patch makes sense, but I don't understand the need for the
second patch.  It suggests that the Tar installer must use libtool,
even though the installation process does not generate a shared
library.  This runs counter to the Libtool manual, which says:

   If you choose at this point to "install" the library (put it in a
   permanent location) before linking executables against it, then you
   don't need to use libtool to do the linking.  Simply use the
   appropriate `-L' and `-l' flags to specify the library's location.

I take this to mean that it's the Tar installer's responsibility to
specify any special options needed to link.

Having Tar use libtool also means that the Tar distribution must
contain ltmain.sh and m4/libtool.m4, and Tar's configure program will
then do all sorts of unnecessary tests that are relevant only for
generating shared libraries.

You write that you run into a problem when you use:

  export CPPFLAGS=-I/tmp/prefix/include LDFLAGS=-L/tmp/prefix/lib

on Yellow Dog GNU/Linux.  I'm not familiar with that platform, but on
the platforms I am familiar with you need to specify -R (for the
runtime path) as well as -L (for the linktime path), e.g.:

  export CPPFLAGS=-I/tmp/prefix/include LDFLAGS='-L/tmp/prefix/lib 
-R/tmp/prefix/lib'

Shouldn't that fix the problem?


> Indeed I'm now considering whether I should add AM_PROG_LIBTOOL to
> gettext.m4, thus forcing every package using libintl to also use
> libtool.

Please don't do that: it will unnecessarily discourage people from
using libintl.  There has to be a better way to address this problem.

Perhaps we need a new autoconf macro to generate the appropriate
linker options, but AC_PROG_LIBTOOL is overkill, as we shouldn't need
to run libtool.