After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 312141 - automake version mismatch (Debian testing)
automake version mismatch (Debian testing)
Status: RESOLVED DUPLICATE of bug 305641
Product: gnome-common
Classification: Core
Component: general
git master
Other Linux
: Normal major
: ---
Assigned To: Gnome Common Maintainer(s)
Gnome Common Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2005-07-31 16:37 UTC by Christian Kirbach
Modified: 2005-08-02 21:59 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Christian Kirbach 2005-07-31 16:37:07 UTC
Version details: latest cvs jhbuild
Distribution/Version: Debian testing

Reproduce: On Debian testing try to build an arbitrary package from the gnome-2.
12 module set.
install automake 1.4,1.6,1.7,1.8,1.9
jhbuild sanitycheck has no complaints

Details:

./autogen.sh --prefix /opt/gnome2  --disable-docs --disable-gtk-doc
/opt/gnome2/bin/gnome-autogen.sh
checking for autoconf >= 2.53...
  testing autoconf2.50... found 2.59
checking for automake >= 1.7...
  testing automake-1.7... found 1.7.9
[...]
Running automake-1.7...
configure.in:31: version mismatch.  This is Automake 1.7.9,
configure.in:31: but the definition used by this AM_INIT_AUTOMAKE
configure.in:31: comes from Automake 1.9.5.  You should recreate
[...]


Remedy:
Drop to shell, run "./configure --prefix=... <otheroptions>", "exit"
and select 'ignore and continue to build'
Comment 1 Christian Kirbach 2005-07-31 21:05:45 UTC
very few modules do not bail out, including poppler
Comment 2 Christian Kirbach 2005-07-31 21:47:27 UTC
looks like autogen problems

as the remedy does not always work, but manually invoking aclocal-1.9 and 
automake-1.9 often gets me past
Comment 3 Christian Kirbach 2005-08-01 08:50:12 UTC
gnome-autogen, to be more prcisely

It seems to *always* detect automake-1.7 , even if that version is not 
installed! Similar probs with most other modules. I believe I have never
seen the most recent automake-1.9 being selected.

Note that I manually set AC_LOCAL_FLAGS to include macros from /opt/gnome2, i.e. 
 a non-standard path.

changing product to gnome-common
Comment 4 Rodney Dawes 2005-08-02 20:07:05 UTC
This sounds like a dup of bug #305641 to me. Though, I don't see how it could
detect something that doesn't exist. It actually runs the automake script to
check that it exists, and to get the version. I'm not sure why it would get the
wrong version of the macro for AM_INIT_AUTOMAKE either. That error shouldn't
occur. Sounds like aclocal is copying the wrong version over. Perhaps because
aclocal and automake version discrepencies exist on the system.
Comment 5 Christian Kirbach 2005-08-02 21:59:42 UTC
OK, the other report gave me inspiration.
I ran jhbuild bootstrap some time ago, so actually automake 1.7 was actually on 
the system.
removing it did force it to use automake 1.9 and get things done.
however the script should indeed pick the latest when possible, i can think of 
no reasons why it should not.

marking duplicate. Thank you.

*** This bug has been marked as a duplicate of 305641 ***