David,
(I'm back)
On Wednesday, April 7, 2004, at 01:55 PM, David Berry wrote:
>>> Yes, I've comitted the autoconf changes, but there are still a
>>> number of
>>> problems which I'm awaiting words of wisdom from Norman on, which is
>>> why I
>>> had not advertised it. At the moment I cannot get a newly checked-out
>>> working directory to bootstrap. I get:
>>
>> I didn't have that problem at all. It builds and installs okay (I
>> haven't
>> checked what gets installed). It's almods like you have some
>> non-buildsupport gnu tools in your path.
>
[...]
> autoreconf --install --symlink
> configure.ac:27: error: possibly undefined macro: AC_PROG_LIBTOOL
>
> autoreconf --install --symlink
> configure.ac:15: version mismatch. This is Automake 1.8.2-starlink,
> configure.ac:15: but the definition used by this AM_INIT_AUTOMAKE
> configure.ac:15: comes from Automake 1.7.5. You should recreate
> configure.ac:15: aclocal.m4 with aclocal and run automake again.
It's a bit odd, but it looks as if autoconf can't find the libtool
macros, and autoreconf can't find the correct automake macros. The
problem is that the autotools have to be able to find each other while
they're themselves being configured, and be built in the correct order.
I think what we're seeing here can happen if your PATH didn't contain
both (in your case) /star/cvs/star/bin _and_
/star/cvs/star/buildsupport/bin _before_ you ran the ./bootstrap which
built the buildsupport tools. When thirdparty/fsf/autoconf is being
configured, I think it establishes the path to libtool and automake,
and their macros, since autoconf doesn't itself have definitions of
AC_PROG_LIBTOOL and AM_INIT_AUTOMAKE (like I've said before, the
autotools have a very unhealthy interdependence on each other).
David, can you bear to try building these again? Remove
/star/cvs/star/buildsupport and the autoconf, automake, libtool and
starconf manifest files, check that /star/cvs/star/buildsupport/bin is
in your PATH, and do ./bootstrap --buildsupport-only in the top level.
After that, try autoreconf in the AST directory.
For what it's worth, I also can boostrap AST, as freshly checked out a
couple of hours ago, on OSX. (I can't build it, because I need to
install g77 for sst's sake, but that's my problem!).
>>> some other issues such as the fact that the dummy headers for ems,
>>> f77 and
>>> slalib are not installed.
>>>
>>
>> Where should they go? Presumably they aren't meant to overwrite the
>> *real*
>> versions of the include files?
>
> Sorry - when I said "installed" what I really meant was that they are
> not
> included in the distribution. They are needed so that AST can be built
> on
> systems which do not have the USSC installed. These header files do not
> actually get installed - they are deleted once AST has been built.
Now that AST's on the trunk, I can set to work on distribution problems
like this.
See you,
Norman
--
----------------------------------------------------------------------
Norman Gray http://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow [log in to unmask]
|