Bug in lib-link.m4 (gettext-0.17)

[Charles Wilson]

The following snippet in lib-link.m4

  dnl Assume the include files are nearby.
  additional_includedir=
  case "$found_dir" in
    */$acl_libdirstem | */$acl_libdirstem/)
      basedir=`echo "X$found_dir" | sed -e 's,^X,,' -e
"s,/$acl_libdirstem/"'*$,,'`
      LIB[]NAME[]_PREFIX="$basedir"
      additional_includedir="$basedir/include"
    ;;
  esac

which occurs around line 413 has the effect of resetting
LIB[]NAME[]_PREFIX as each dependencies of NAME is found.  For instance,
in the test case rpath-3abh, the configure script is searching for
librpathz, which depends on librpathy (which in turn depends on librpathx).

The first time thru the loop surrounding the snippet above, librpathz is
found, and LIB[]NAME[]_PREFIX (which resolves to LIBRPATHZ_PREFIX) is
correctly set to "$builddir/$rp-prefix3".  However, because librpathz
depends on librpathy, there is another loop -- and this time, librpathy
is found in $builddir/$rp-prefix2/lib, so LIBRPATHZ_PREFIX is *reset* to
"$builddir/$rp-prefix2".  Further, because librpathy depends on
librpathx, there is a THIRD loop...

So, the Makefile in this case ends up with the following nonsense:

LIBRPATHZ = $builddir/rp3abh-prefix3/lib/librpathz.dll.a
-L$builddir/rp3abh-prefix1/lib -L$builddir/rp3abh-prefix2/lib
$builddir/rp3abh-prefix2/lib/librpathy.dll.a
$builddir/rp3abh-prefix1/lib/librpathx.dll.a
-L$builddir/rp3abh-prefix3/lib -L$builddir/rp3abh-prefix1/lib
-L$builddir/rp3abh-prefix2/lib

LIBRPATHZ_PREFIX = $builddir/rp3abh-prefix1
^^^^^ THIS IS THE ERROR. SHOULD BE $builddir/rp3abh-prefix3 ^^^^^^

LTLIBRPATHZ = -L$builddir/rp3abh-prefix3/lib -lrpathz
-L$builddir/rp3abh-prefix1/lib -L$builddir/rp3abh-prefix2/lib
-L$builddir/rp3abh-prefix2/lib -lrpathy -L$builddir/rp3abh-prefix1/lib
-lrpathx -R$builddir/rp3abh-prefix3/lib -R$builddir/rp3abh-prefix1/lib
-R$builddir/rp3abh-prefix2/lib

There are some other issues that are cygwin-specific (more later), but
this one seems like it is probably a cross-platform bug, and thus should
be higher priority.

The other variables LIB[]NAME and LTLIB[]NAME are OK, because they
accumulate the contributions from each dependency, but
LIB[]NAME[]_PREFIX is reset each time, so only it exhibits this bug --
it retains the prefix to the last searched dependency of libNAME, not
the prefix of libNAME itself.

Unfortunately I don't have a patch or suggestion on how this should be
fixed.

--
Chuck