GNOME Bugzilla – Bug 305641
Prefer newer versions of Automake
Last modified: 2005-09-20 09:41:55 UTC
Currently, gnome-autogen.sh uses the oldest version of automake which satisfies REQUIRED_AUTOMAKE_VERSION. This means that gnome tarballs are often built with automake-1.6 or automake-1.7. But those versions were very buggy. For example they didn't support linking with uninstalled libtool libraries correctly, see the bug #305544. It took me many hours to find the solution. I think the tarballs would be much more useful if they were built with recent autotools. Thusly, gnome-autogen.sh shoul prefer newer versions of automake.
Created attachment 46938 [details] [review] patch to prefer newer automake This patch PREFER_NEWER_AUTOMAKE. It also adds a comment explaining why this should be the default.
*** Bug 305544 has been marked as a duplicate of this bug. ***
Comment on attachment 46938 [details] [review] patch to prefer newer automake I forgot to say that the patch has to be applied after the three patches from bug #169960. Originally, I postpone writing this patch until #169960 is resolved. But when the same bug hit from another side, I had to fix the problem at least on my computer.
I don't like this patch. It also seems fairly pointless to me. Things will only get disted with newer versions of automake if we make it a requirement and enforce it, not if we just simply add something to gnome-common that nobody will ever use unless they are told to or someone gives them a patch. Aside from that though, the patch just seems a bit off. It just checks for the "automake" binary first, which may or may not be what you want. It is a symlink, and what it is linked to, depends on the install order of automake versions, or perhaps what the alternatives system in use is set to use. The point of the existing checks is that they avoid the "automake" symlink/script entirely, and always ends up pointing to the versioned copies. If you want to prefer newer versions, perhaps we should just go back to checking the scripts in the reverse order, so that for 1.5, we check 1.9, 1.8, 1.7, 1.6, and then 1.5. The large comment in the patch also seems like something that should be sent to a mailing list, or said in this bug report, rather than in a comment. It's asking whether or not we should do this, and pointing out a couple of pros and cons of the situation. I think that ideally, if we want to ensure that things are disted with certain versions of tools, we should create developer policy for doing releases of modules, and some method of enforcement for it. We could easily modify the script to push tarballs to ftp, to check versions of tools that the tarball was built against, and enforce it that way. I'm sure we could do some other pieces of enforcement, through gnome-common as well, but I don't think this patch as it stands, is how we should go about doing that.
Created attachment 48439 [details] [review] a lighter version Rodney, thank you for your comments. Did I understand correctly that it would be easier to start from this simple patch? Stepan
Yeah. This patch would prefer newer versions by default, but still allow the older ones to work.
James? Can Stepan commit this please? It looks fine to me.
*** Bug 312141 has been marked as a duplicate of this bug. ***
Confirming this report. The script should indeed pick the latest when possible, i can think of no reason why it should not. On the contrary the current behaviour has proven to cause problem.
bug 128691 details the Rodney's original change from "pick latest version if > 1.4 was requested" to "pick oldest version if > 1.4 requested". I guess it is worth making the change and seeing what breaks. I'll do a jhbuild run with this change and see if it causes any obvious problems. If not, I'll commit the change.
I've run into some configure issues in gnome-vfs, probably due to evil usage of automake M4 macros (e.g. using AM_CONDITIONAL() within a conditional section). Will see if there are any more.
The gnome-vfs problem: see bug #313753. (As you can read there, aclocal-1.6 indeed hides this bug.)
Well, only 1 module having trouble with the change is quite promising. Once gnome-vfs gets fixed, we may as well make the change. Of course, I've only tested the ability to go as far as "make install". There may be other issues that will only present themselves when people try to run "make distcheck".
looks good, this seems to be fixed for me. now that the second patch has been applied, shall we tag it "committed"?
or perhaps not ... when jhbuilding gnome-session it detects AM 1.7 (1.9 is installed as well) and bails out Running automake-1.7... configure.in:4: version mismatch. This is Automake 1.7.9, configure.in:4: but the definition used by this AM_INIT_AUTOMAKE configure.in:4: comes from Automake 1.9.5. You should recreate configure.in:4: aclocal.m4 with aclocal and run automake again.
Neither of the patches on this bug have been committed yet, so I'm not sure how that error would have occurred. Could you attach the full autogen.sh output to this bug?
applying the patch does not make any difference *** Configuring gnome-common *** [3/40] ./autogen.sh --prefix /opt/gnome2 --disable-docs --disable-gtk-doc checking for autoconf >= 2.53... testing autoconf2.50... found 2.59 checking for automake >= 1.7... testing automake-1.7... found 1.7.9 Checking for forbidden M4 macros... Processing ./configure.in Running aclocal-1.7... Running autoconf2.50... Running automake-1.7... configure.in:6: version mismatch. This is Automake 1.7.9, configure.in:6: but the definition used by this AM_INIT_AUTOMAKE configure.in:6: comes from Automake 1.9.5. You should recreate configure.in:6: aclocal.m4 with aclocal and run automake again. *** error during stage configure of gnome-common: could not configure module *** [3/40]
I really doubt you have the gnome-common patch applied, since it would check for automake-1.9 first -- your paste shows that it is checking for automake-1.7 first (the behaviour without the patch). This error is very weird. What do you have $ACLOCAL_FLAGS set to? Does the error go away if you delete aclocal.m4 first?
Since I haven't been able to reproduce Christian's problem, I've gone ahead and applied the second less invasive to the HEAD of gnome-common. Before doing so, I created a gnome-2-12 branch (and a 2.12.0 tarball) in case this shows up any problems (none of the core Gnome modules exhibited problems but other software might).
I am sorry for loosing track of this .. the errors most likeley were because of a broken automake installation. Since upgrading Debian thoroughly I haven`t had any issues. Anyway the precautions are just fine.