Hello Michael, Harlan,
* Harlan Stenn wrote on Wed, Jul 25, 2007 at 07:44:07PM CEST:
Hi! I write to you directly because I have a problem that, searching
through Google, you posted to the autoconf mailing list with the same
problem...but the solution itself was not posted.
OK, and I'm adding address@hidden to my response.
Thanks. FWIW, this is probably an aclocal issue (aclocal is part of
Automake).
You had a problem in which you had to run autoreconf in order to do
something with ntpd. However, you were getting errors like this:
possibly undefined macro: AC_PROG_LIBTOOL
possibly undefined macro: AC_DISABLE_SHARED
How did you solve this problem?
Best I can remember I added a -I/path/to/libtool/automacros/ to the
ACLOCAL flags on the machine that gives me this problem.
And it makes no sense to me why this should be needed - from my POV
automake, autoconf, and libtool should know how to play nice together
but libtool has problems in this regard way too often.
Well, really this happens every time you install packages that install
their own macro files, but you install in a different --prefix than
where Automake is installed. What you can do to have aclocal find them
all the time is
echo $libtool_prefix/share/aclocal >> $automake_prefix/share/aclocal/dirlist
but you cannot use this setup to support multiple Libtool installations
in parallel.
The same issue will happen with other packages that install their own
.m4 macro files, such as gettext, bison, etc.
A long time ago the folks who wrote a modules.sf.org-friendly ports
system (I think they were at kth.se) had a patch to (near as I can
remember) add a new environment variable to aclocal so one could easily
support multiple installed versions of libtool. I tried to get that
patch accepted into the mainstream auto* codebase but was unsuccessful.
I suppose, if you use autoreconf, you can use
ACLOCAL="aclocal -I $libtool_prefix/share/aclocal"
Otherwise, Harlan could you point to the thread where the patch was
rejected? Thanks.
Cheers,
Ralf