GNU bug report logs -
#19370
LT 2.4.4 regression (vs. 2.4.2)
Previous Next
Full log
View this message in rfc822 format
On Dec 22, 2014, at 4:22 PM, Gary V. Vaughan <gary <at> vaughan.pe> wrote:
> Indeed it is. And the problem is that autoreconf, as called from the autogen.sh in the tarball, still runs the tools in the wrong order.
(first day back in the office today -- just seeing your reply now...)
Ah! Ok.
> Autoreconf stupidly runs aclocal first, and then calls libtoolize which adds more m4 files to AC_CONFIG_MACRO_DIR, and that in turn causes aclocal.m4 to be out of date (because it needs to be regenerated to pick up the local versions of the libtoolize added m4 files added to ../config/ after it was first generated).
>
> The bootstrap script in the libtool source tree fixes this (and many other problems with the autogen.sh/autoreconf approach), so if you care to write a bootstrap.conf (by copying and hacking nearly everything out of libtool-2.4.4/bootstrap.conf), things are then created in the right order and the bug disappears.
That's a bummer. We always thought that The Recommended Way to run the autootols was to use autoreconf. Specifically: we used to have a magic incantation of a specific order of Autotools to bootstrap OMPI. But that ordering was only "mostly" correct, meaning that upgrading Autotools sometimes broke it, because we didn't have the order exactly right... My memory of the details is fuzzy here; I just remember it was a great relief when we trashed the whole thing and replaced it with a single invocation of autoreconf.
> Alternatively, you can amend your autogen.sh to something like this:
>
> libtoolize --install --copy --ltdl
> LIBTOOLIZE=true autoreconf -fvi
Just to be clear: you're saying that I should invoke libtoolize *before* autoreconf, right? (as opposed to appending those 2 lines at the end of my existing autogen.sh script)
I'm pretty sure that's what you're saying, and indeed, if I make my autogen.sh be this:
-----
$ more autogen.sh
#!/bin/sh
libtoolize --install --copy --ltdl
autoreconf -ivf --warnings=all,no-obsolete,no-override -I config
-----
...then the problem goes away. Yay!
> If it worked for you in 2.4.2 in that order, then it was just a lucky combination of an empty local directory and installed versions of the macro files in the right place for aclocal.m4 to be valid on the initial too-early run.
Ever since we switched to invoking a single autoreconf (which was a loooong time ago; I'd have to go spelunking through history to find out when it was done, but it was probably on the order of years ago), we've not invoked libtoolize before autoreconf.
So just to be crystal clear: is the official guidance that we should run libtoolize and then autoreconf, and that should always work?
> In your original report, however, you said:
>
> "The problem appears to be that make is checking for ../m4/libtool.m4 file as a dependency. This file file -- and the entire ../m4 directory, for that matter -- does not exist. So make decides to fire the "run the aclocal" rule."
>
> ...which seems odd to me, because for a subproject libltdl, the parent AC_CONFIG_MACRO_DIR/ACLOCAL_AMFLAGS directory is supposed to be merged in. Did you mean to say "../config/libtool.m4" above? If that substitution really isn't happening, then you've found a different bug - but I can't reproduce that one with 2.4.3, 2.4.4 nor current master.
I don't remember, and since you can't reproduce it, let's assume that I made a user error and I really did mean "../config/libtool.m4". :-)
--
Jeff Squyres
jsquyres <at> cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
This bug report was last modified 10 years and 104 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.