autoconf/automake/libtool trouble

Alexander E. Patrakov semzx at newmail.ru
Sat Jan 10 05:54:59 PST 2004


Greg Schafer wrote:

>On Sat, Jan 10, 2004 at 04:28:43PM +0500, Alexander E. Patrakov wrote:
>  
>>2) The case with a bug - autoconf used
>>
>>tar zxf gd-2.0.19.tar.gz    # (2.0.15 also has the problem)
>>cd gd-2.0.19
>># Here I tried patching in GIF support, let's skip this patch.
>># After patching, autotools should regenerate the ./configure script
>
>Bzzzt! Wrong assumption. Autotools are not smart enough yet to figure out
>when to rerun libtoolize by itself. For now, the end-user must know when to
>do it him/her self.
>
Probably I didn't formulate the thing clearly enough. After patching,
since the patch modified Makefile.am, I should run aclocal, autoheader,
autoconf, automake. I did that. Only then I realized that for some
unknown reason I should also run libtoolize --force.

Also, to rule out badly written patch, I executed these commands in the
freshly unpacked source tree, without any patch. Since the problem 
reappeared, I assumed it's with autotools. That's what my first report 
is about.

AFAIK libtoolize only adds config.guess, config.sub and ltmain.sh
symlinks. Which of these files is responsible for guessing the shared
library extension? Why did the old code break? I understand that auto*
commands are needed when I change the Makefile.am file. But sometimes
libtoolize --force is needed and sometimes not. What is the exact
condition? Where in documentation is it stated?

In other words: which file changed by invocation of autoheader, aclocal,
autoconf, automake causes ltmain.sh in the package to become out-of-date?

-- 
Alexander E. Patrakov






More information about the lfs-support mailing list