Automake is giving this error message:

Libtool library used but 'LIBTOOL' is undefined
The usual way to define 'LIBTOOL' is to add `AC_PROG_LIBTOOL'
to `configure.ac' and run `aclocal' and `autoconf' again.

AC_PROG_LIBTOOL is already in 'configure.ac', and running 'aclocal' then 'autoconf' does eliminate the error.

BUT unfortunately this error happens during an rpmbuild, where running aclocal and autoconf is not an option. (That is, the sources are unpacked from a tarball by rpmbuild. I'm not is a position to change the original sources, and rpmbuild just does configure then make install.)

The source compiles fine on another system, so I think the cause is some misconfiguration on my machine. The machine is running CentOS 4.1 (yes, it's past time to upgrade, but the app I'm building requires 4.1)

How can I track down what causes the problem? I'm totally new to Automake (and only have superficial knowledge of Linux in general) but I can follow clues, so any suggestions will be much appreciated.

check that LIBTOOL is installed
if not install it

This suggests to me that whoever released the package forgot to rerun the autotools first. If a package has a configure script, the user building the package should not need to use any autotools.


If you can't fix the source, perhaps defining LIBTOOL in the environment will help:

1 members found this post helpful.

Thanks for the suggestions. Libtool is installed
But even with LIBTOOL defined on the rpmbuild command line, the same error occurs.
Guess the source will have to be changed ... but I do wonder how it builds on a different machine. What kinds of things would I look at in comparing the two machines, the one that build vs the one that fails? Fwiw they're running different versions of Centos (3.x on the OK box, 4.1 on the box that fails ... there's work going on to move to Centos 5 soon, though.)

Thanks!

Hmm, it looks like rpmbuild ends up doing more than just configure. Can we look back a bit farther to see how it ended up running automake? Is it possible that the timestamps on some of the files got screwed up? Autoconf puts rules to rerun automake and friends unless maintainer mode is disabled, possibly those rules are getting triggered erroneously. Can you tell rpmbuild to pass --disable-maintainer-mode to configure (see missing and AM_MAINTAINER_MODE)?

Cool! Thanks so much for shedding light!

Adding --disable-maintainer-mode to configure's command line stops the problem; and the Automake manual says if AM_MAINTAINER_MODE is in configure.ac (it is not there at present) then make will never attempt to rebuild, so that gives me two options to stop the problem. Not wishing to look a gift horse in the mouth(*), but ideally it would be best if I did not change the sources in sccs, so is there a third way, perhaps by changing the environment or by touching the timestamps on the files from sccs (though that sounds yucky)?

I'm not sure which files' timestamps are relevant. The libedit source files are pulled from sccs for each build, so they get the current date as timestamps; is that what triggers the rerun? They will be getting similar timestamped on the machine where this problem doesn't happen, so I'm guessing the solution may be other than timestamps (even if timestamps are the cause.) Would some kind of comparison of the environment that fails vs. the environment on the machine that does not fail give more clues?

Configure isn't called directly from rpmbuild (unfortunately, because I can easily change the spec file); the spec file does:
and build.sh (stored in sccs, with the libedit sources) is:
where adding disable-maintainer-mode did the trick:
(*) look a gift horse in the mouth -- though this seems too archaic an expression when discussing computing.

Many thanks again, and apologies for verbosity!

Hmm, I think the maintainer-mode option should not be available at all if AM_MAINTAINER_MODE is not used, weird...

I think the rerun will be triggered if the timestamp on configure.ac is newer than configure, or Makefile.am is newer than Makefile.in. Perhaps sccs doesn't check out all the files at the same time, ie it happened that configure.ac and Makefile.am got checked out last (or at least later than configure and Makefile.in). So try to touch all the configure Makefile.ins.

If the sccs checkout is the cause of the bad timestamps, then it means there is effectively a race condition in the sccs pull command. That's really yucky, touching up the timestamps would be the cleanest fix, in that case.

nothign is wrong or broken

yes ^^ was right you need (right version) of libtools installed if pkg does not have libtools in it: however ^^ was wrong , nothing is broken no-one "forgot"

if one does rtfm: it's optional for a pkg to include (mini libtool, part of libtools) inside the package. doing so bloats small releases and also isn't as capable as a fully installed libtool - thus may not be able to do what it should (in the future)

that's what the manual says

after 3 YEARS
why post a flamming post

post reported