LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.

Notices


Reply
  Search this Thread
Old 10-21-2011, 06:08 PM   #1
anadem
LQ Newbie
 
Registered: Sep 2008
Posts: 16

Rep: Reputation: 0
Automake wants 'LIBTOOL' defined ... but what is the real problem?


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.
 
Old 10-21-2011, 10:14 PM   #2
gary185
Member
 
Registered: Jul 2011
Posts: 113

Rep: Reputation: Disabled
check that LIBTOOL is installed
if not install it
 
Old 10-22-2011, 10:45 AM   #3
ntubski
Senior Member
 
Registered: Nov 2005
Distribution: Debian, Arch
Posts: 3,774

Rep: Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081
Quote:
Originally Posted by anadem View Post
AC_PROG_LIBTOOL is already in 'configure.ac', and running 'aclocal' then 'autoconf' does eliminate the error.
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.


Quote:
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.)
If you can't fix the source, perhaps defining LIBTOOL in the environment will help:

Code:
LIBTOOL="$(which libtool)" rpmbuild package.rpm
 
1 members found this post helpful.
Old 10-24-2011, 07:34 PM   #4
anadem
LQ Newbie
 
Registered: Sep 2008
Posts: 16

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by ntubski View Post
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:

Code:
LIBTOOL="$(which libtool)" rpmbuild package.rpm
Thanks for the suggestions. Libtool is installed
Code:
[bot@wvidbrlnxvm01 mybld]$ which libtool
/usr/bin/libtool
But even with LIBTOOL defined on the rpmbuild command line, the same error occurs.
Code:
[bot@wvidbrlnxvm01 mybld]$ LIBTOOL=/usr/bin/libtool  rpmbuild -vv -bc --target=x86_64 <<etc>>
Building target platforms: x86_64
<<SNIP>>
 cd . && /bin/sh /tmp/mybld/BUILD/orbital-6.1.0/lib/libedit/missing --run automake-1.9 --foreign
src/Makefile.am:31: Libtool library used but `LIBTOOL' is undefined
src/Makefile.am:31:
src/Makefile.am:31: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
src/Makefile.am:31: to `configure.ac' and run `aclocal' and `autoconf' again.
make: *** [Makefile.in] Error 1
<<SNIP>>
error: Bad exit status from /tmp/mybld/tmprpm/rpm-tmp.53289 (%build)
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!
 
Old 10-25-2011, 01:27 PM   #5
ntubski
Senior Member
 
Registered: Nov 2005
Distribution: Debian, Arch
Posts: 3,774

Rep: Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081
Quote:
Originally Posted by anadem View Post
cd . && /bin/sh /tmp/mybld/BUILD/orbital-6.1.0/lib/libedit/missing --run automake-1.9 --foreign
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)?
 
Old 10-26-2011, 02:15 PM   #6
anadem
LQ Newbie
 
Registered: Sep 2008
Posts: 16

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by ntubski View Post
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)?

Quote:
Originally Posted by ntubski View Post
Is it possible that the timestamps on some of the files got screwed up?
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:
Code:
pushd lib/libedit
./build.sh
popd
and build.sh (stored in sccs, with the libedit sources) is:
Code:
#!/bin/bash
./configure --prefix=${PWD}/build --oldincludedir=${PWD}/build/include/old --disable-maintainer-mode
make install
cp build/lib/libedit.a libedit.a
cp build/lib/libedit.la libedit.la
cp build/lib/libedit.so libedit.so
cp build/lib/libedit.so.0 libedit.so.0
cp build/lib/libedit.so.0.0.26 libedit.so.0.0.26
where adding disable-maintainer-mode did the trick:
Code:
./configure  --disable-maintainer-mode --prefix=${PWD}/build --oldincludedir=${PWD}/build/include/old
(*) look a gift horse in the mouth -- though this seems too archaic an expression when discussing computing.

Many thanks again, and apologies for verbosity!
 
Old 10-26-2011, 07:56 PM   #7
ntubski
Senior Member
 
Registered: Nov 2005
Distribution: Debian, Arch
Posts: 3,774

Rep: Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081
Quote:
Originally Posted by anadem View Post
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.
Hmm, I think the maintainer-mode option should not be available at all if AM_MAINTAINER_MODE is not used, weird...

Quote:
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?
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.

Quote:
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)?
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.
 
Old 12-31-2014, 02:21 PM   #8
debguy
Member
 
Registered: Oct 2014
Location: U.S.A.
Distribution: mixed, mostly debian slackare today
Posts: 207

Rep: Reputation: 19
Broken ?

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
 
Old 12-31-2014, 07:34 PM   #9
John VV
LQ Muse
 
Registered: Aug 2005
Location: A2 area Mi.
Posts: 17,622

Rep: Reputation: 2651Reputation: 2651Reputation: 2651Reputation: 2651Reputation: 2651Reputation: 2651Reputation: 2651Reputation: 2651Reputation: 2651Reputation: 2651Reputation: 2651
after 3 YEARS
why post a flamming post

post reported
 
  


Reply

Tags
automake, centos4, libtool, rpmbuild


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Installing automake,libtool and gcc on Mandrake 9.2 Mizar81 Mandriva 1 11-10-2008 01:47 AM
LXer: The good and the bad with Autotools, Autoconf, Automake and Libtool for open so LXer Syndicated Linux News 0 05-09-2008 09:12 PM
libGL.la problem with libtool ppr:kut Linux - Software 4 11-01-2006 05:01 AM
Scribus installation problem, sez I need automake 1.6 when automake 1.9 is istalled Rockgod2099 Linux - Software 13 11-14-2004 06:37 PM
problem when configuring libtool-1.5.6 arion Linux - Newbie 1 10-29-2004 11:16 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 07:42 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration