against libtool a few years ago, but it was said that the bug was in
autoconf or automake (then, I suspect automake). I don't know whether
something has been done on the automake side; I don't have access to
HP-UX machines any longer.
The problem is the following.
To be able to build the MPFR library, the user may need to add some
search path when invoking configure, in order to find the GMP library
(on which MPFR depends). This is done via LDFLAGS, either explicitly
or by the configure script if the user has provided a --with-gmp=DIR
option. The setting of LDFLAGS for such a purpose is standard and
documented in the Automake manual (AM_LDFLAGS could be used too, with
the same effect).
Then, for "make check", the path to the MPFR library that has just
been built or the library filename itself must be added to the link
command by the autotools (automake?). Under GNU/Linux, the filename
../src/.libs/libmpfr.so is used, and there are no problems. But under
HP-UX, it is the path that is added (here, the -L../src/.libs flag),
and this is done in LIBS, which appears at the end of the command,
and in particular *after* $(LDFLAGS):
This means that search paths added via AM_LDFLAGS and/or LDFLAGS have
the precedence over the local search path, and if an old version of
the library is installed in some LDFLAGS search path (which happens),
it will be used for "make check" instead of the library that has just