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 323282 - Intltool incompatible with Automake 1.4 (and packages not using automake)
Intltool incompatible with Automake 1.4 (and packages not using automake)
Status: RESOLVED OBSOLETE
Product: intltool
Classification: Deprecated
Component: general
0.34.x
Other All
: Normal normal
: ---
Assigned To: intltool maintainers
intltool maintainers
: 322584 322586 322659 322663 322847 322875 322876 322878 336694 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-12-05 16:33 UTC by Christian Kirbach
Modified: 2007-08-03 00:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
log of jhbuild for procman (46.60 KB, text/plain)
2005-12-06 04:22 UTC, sobhi
  Details
config.log from jhbuild run on procman (49.38 KB, text/plain)
2005-12-06 04:23 UTC, sobhi
  Details
default to automake 1.9 instead of 1.4 (1.19 KB, patch)
2005-12-12 00:12 UTC, Christian Kirbach
none Details | Review

Description Christian Kirbach 2005-12-05 16:33:42 UTC
Please describe the problem:
From Bug #322663

There's an installation failure in many/most Gnome apps because the Makefile.in.
in has a variable
install_sh = @install_sh@ that it can't resolve. This is due to new changes from
intltool. Once the correct Makefile is created it has to point to

$(top_builddir)/install-sh


Steps to reproduce:
1. checkout latest intltool and one of the Gnome 2.12 modules from the 
duplicates
2. autogen, make && make install


Actual results:
@install_sh@ not replaced properly

Expected results:
@install_sh@ point to somewhere appropriate

Does this happen every time?
yupp

Other information:
Comment 1 Christian Kirbach 2005-12-05 16:35:48 UTC
*** Bug 322663 has been marked as a duplicate of this bug. ***
Comment 2 Christian Kirbach 2005-12-05 16:36:21 UTC
*** Bug 322875 has been marked as a duplicate of this bug. ***
Comment 3 Christian Kirbach 2005-12-05 16:36:31 UTC
*** Bug 322876 has been marked as a duplicate of this bug. ***
Comment 4 Christian Kirbach 2005-12-05 16:36:36 UTC
*** Bug 322878 has been marked as a duplicate of this bug. ***
Comment 5 Christian Kirbach 2005-12-05 16:36:45 UTC
*** Bug 322847 has been marked as a duplicate of this bug. ***
Comment 6 Christian Kirbach 2005-12-05 16:36:53 UTC
*** Bug 322659 has been marked as a duplicate of this bug. ***
Comment 7 Christian Kirbach 2005-12-05 16:40:15 UTC
This affects many modules and has been confirmed before.
Comment 8 Rodney Dawes 2005-12-05 19:26:53 UTC
OK. I have no idea why this is happening. I need a lot more info. I need to know
the PATH and ACLOCAL_FLAGS variables that configure has. I just tried mixing
0.34.1 with a CVS install, and everything still works fine here. How can I
duplicate this? A simple run of autogen.sh doesn't do it.
Comment 9 Christian Kirbach 2005-12-05 20:42:53 UTC
ok, I can reproduce with

 $ jhbuild buildone -a at-spi

using the Gnome 2.12 module set.

...
config.status: executing po/stamp-it commands
config.status: error: po/Makefile is not ready.
*** error during stage configure of at-spi: could not configure module *** [1/1]


nazgul@demonhide:~$ echo $PATH
/opt/jdk1.5.0_04/bin:/opt/gnome2/bin:/opt/gnome2/sbin:/usr/local/bin:/usr/bin:/
bin:/usr/bin/X11:/usr/games:/home/nazgul/bin

nazgul@demonhide:~$ echo $ACLOCAL_FLAGS
-I /opt/gnome2/share/aclocal

$ which intltoolize
/opt/gnome2/bin/intltoolize
Comment 10 Christian Kirbach 2005-12-05 21:01:56 UTC
stupid me, that is a different issue.

so, finally this his how to reproduce:

 nazgul@demonhide:~$ jhbuild buildone -a procman



*** Installing procman *** [2/34]

make   install
Making install in po
make[1]: Entering directory `/multimedia/cvs/gnome2/procman/po'
make[1]: install_sh@: No se encontró el programa



 $ intltoolize --version
intltoolize (GNU intltool) 0.34.1
Comment 11 Christian Kirbach 2005-12-05 21:08:34 UTC
$ jhbuild buildone -a gdl

also reproduces
Comment 12 Rodney Dawes 2005-12-05 21:12:00 UTC
OK. Well, that one is an at-spi bug. It's calling AC_PROG_INTLTOOL in
configure.in, but the bits to use AM_GLIB_GNU_GETTEXT are commented out, and the
AC_OUTPUT section, does not include po/Makefile.in.
Comment 13 Rodney Dawes 2005-12-05 21:17:53 UTC
install_sh = /home/dobey/Projects/procman/install-sh

Well. Looks like procman works here too... What version of autoconf are you using?
Comment 14 Rodney Dawes 2005-12-05 21:20:52 UTC
And gnome-backgrounds also works for me. I'm inclined to say that this is a
problem with jhbuild, and not intltool.
Comment 15 Christian Kirbach 2005-12-05 21:27:23 UTC
autoconf (GNU Autoconf) 2.59
Comment 16 Christian Kirbach 2005-12-05 22:07:11 UTC
I haven't changed or updated jhbuild in weeks, but I upgraded intltool
shortly before the errors.

If you still think this is jhbuild, then please reassign.
Comment 17 Ali Akcaagac 2005-12-05 22:41:54 UTC
I don't use jhbuild but cvsgnome and see the same errors. That's why I initially
reported this bug. So, since this happens with jhbuild and my very own cvsgnome
script. This seem to be more an intltool issue rather than a buildscript one.

The infrastructure of CVSGnome can be seen here:

http://www.akcaagac.com/index_cvsgnome.html
Comment 18 Ali Akcaagac 2005-12-05 22:43:24 UTC
Oh, and my script hasn't changed since (11-08-2005), so you can imagine that I
build GNOME a dozen times meanwhile till I hit the problem recently.
Comment 19 Rodney Dawes 2005-12-05 23:03:13 UTC
Well. The build scripts not changing is of little consequence. A change in a
number of other packages could expose a problem in the build scripts.

I don't use either, and I am unable to reproduce the problem on two machines
with intltool CVS.

And, I can't reproduce the problem with builddir != srcdir with gnome-common and
intltool both installed from HEAD. I've no idea what else it could be. 
Comment 20 Rodney Dawes 2005-12-05 23:24:57 UTC
<thos> dobeywork, yes it seems to autogen fine outside of jhubild

As it does for me. I'm reassigning this to jhbuild then. I can't reproduce the
problem outside of it. If someone can reproduce the problem without jhbuild,
cvsgnome, or some other similar build script, and with straight ./autogen.sh,
then please reassign back to intltool with more info.
Comment 21 James Henstridge 2005-12-06 02:00:10 UTC
For one of the problem modules, could you do a "make distclean", and then do
"jhbuild buildone -a modulename".  Then attach a copy of the config.log file
that gets generated?
Comment 22 sobhi 2005-12-06 04:22:25 UTC
Created attachment 55665 [details]
log of jhbuild for procman
Comment 23 sobhi 2005-12-06 04:23:27 UTC
Created attachment 55666 [details]
config.log from jhbuild run on procman
Comment 24 James Henstridge 2005-12-06 05:34:20 UTC
This looks like an intltool bug.

Rodney: I see that you use @install_sh@ in intltool's Makefile.in.in.  Where do
you expect that substitution to be defined?  It doesn't get defined anywhere in
your M4 macro.

Autoconf does define an @INSTALL@ substitution.  Perhaps that's what you
intended to use instead?
Comment 25 James Henstridge 2005-12-06 05:44:56 UTC
More info: automake's AM_PROG_INSTALL_SH macro will define @install_sh@, and is
called by AM_INIT_AUTOMAKE.

This does not occur with procman because it is using Automake-1.4, which does
not define the variable.

Can someone check to see if any of the affected modules are not using
automake-1.4? (you can check this by reading the first few lines of the
generated toplevel Makefile.in).

If they are all automake-1.4 holdouts, then there are two ways of interpreting
this bug:
 1) intltool should work with automake-1.4 but doesn't.
 2) intltool requires a newer version of automake, so the problem modules
    should be updated.

If intltool is meant to work in the absense of automake, then the bug would
almost definitely be (1).  If it is (2), then intltool should be checking the
automake version (not sure of the best way to do that).
Comment 26 sobhi 2005-12-06 06:10:55 UTC
I checked the following (procman, gnome-mag, memprof, gnome-background,
nautilus-vcs) and all have " automake 1.4-p6" on the first line of the Makefile.in.
Comment 27 James Henstridge 2005-12-06 07:13:32 UTC
Okay then.  Back to dobey.

For reference, the @install_sh@ variable seems to have remained unexpanded in
those modules for a long time.  The problem only reared its head when
@install_sh@ started getting used recently:

  1.2  (dobey 04-Nov-04): install_sh = @install_sh@
  1.14 (dobey 24-Nov-05): # Automake >= 1.8 provides @mkdir_p@.
  1.14 (dobey 24-Nov-05): # Until it can be supposed, use the safe fallback:
  1.14 (dobey 24-Nov-05): mkdir_p = $(install_sh) -d
Comment 28 sobhi 2005-12-06 17:16:44 UTC
This is very disturbing. I just did a find for all the "Makefile" in the source
directory where I build Gnome 2.12.2 "grep"ing for strings "@[^ ]@" indicating
unresolved variables. There are a lot of them. This is incredible. What's going on?
Comment 29 sobhi 2005-12-06 17:22:21 UTC
sorry. "grep"ing for strings "@[^ ]*@" to indicate the unresolved variables.
There was typo ;-(
Comment 30 sobhi 2005-12-09 16:02:52 UTC
any body successful in resolving this blocker?
Comment 31 bill.haneman 2005-12-09 16:11:36 UTC
at-spi seems to have this problem too, but it requires automake 1.7 (!)
Comment 32 Christian Kirbach 2005-12-09 16:31:27 UTC
at-spi (automake 1.7) builds fine here with jhbuild and intltool 0.34.1.
But procman (automake 1.4) does not.


I added
 REQUIRED_AUTOMAKE_VERSION=1.7 
to the last line of autogen.sh in the procman top dir, and then it
seems to work. No error.
I have not tested if all other modules can be shifted easily to a newer version 
(though I think it makes sense, but not sure), but this still is just a 
workaround.
Comment 33 Christian Kirbach 2005-12-09 16:53:46 UTC
I reverted the changes and made gnome-autogen.sh default to automake 1.9.
at-spi, procman and gdl all build fine now.

I encourage you to set
 REQUIRED_AUTOMAKE_VERSION=${REQUIRED_AUTOMAKE_VERSION:-1.9}

in gnome-autogen.sh and see if it breaks any modules.
Comment 34 Rodney Dawes 2005-12-09 16:56:49 UTC
Bill: at-spi has a different problem. See comment #12 in this same bug. You have
translations disabled, but only partially.

Everyone else: I'm not sure how to fix this for automake 1.4. I think the fact
that automake 1.4 is still being used, is due to people not updating their
autogen.sh to require 1.5 or newer, and the fact that gnome-common defaults to
it. Frankly, I think it's time we stop using 3 year old build tools, when there
are much newer and actively maintained versions available. Outside of copying
the macros to do the new stuff that newer automakes handle, into intltool
directly, there isn't really any easy way to solve this. We need to move people
off of 1.4. I think we should change gnome-common to default to the latest
released version of automake, and people who really need 1.4, can specify that
they need 1.4. What do you think James? Can we make gnome-common default to the
new versions, and then push people to fix bugs and breakage in their modules? I
don't even have automake 1.4 installed any more. We no longer ship it in NLD at
least. I don't think I've installed it on any of my slackware machines either.
Comment 35 James Henstridge 2005-12-10 03:05:13 UTC
Before changing the default requested version, I'd want to do one of the following:
 * convert all Gnome desktop and developer platform modules to newer automake
 * make the remaining 1.4-using modules explicitly request that version.

One of these would be necessary to keep everything building during the transition.

That is not a full solution to this bug though.  It would probably help to make
the intltool autoconf macro check what automake version is being used, and fail
if it is too old.  You could do that with something like this:
  case "$am__api_version" in
    1.[01234])
      AC_MSG_ERROR([Intltool does not support Automake 1.4. etc])
      ;;
    *)
      ;;
  esac

Also, there is one error in your previous comment: Automake 1.4 is actually
closer to being 7 years old -- the 3 year old version of Automake is now 1.7. 
Of course, this makes it sound even worse ...
Comment 36 Christian Kirbach 2005-12-12 00:12:06 UTC
I have built the Gnome-2-12 branch (except Evolution*) and found out that the 
workaround seems to work and it does not break any 2.12 modules.

This also plays along nicely with Bug #305641.

I am attaching a suggested patch for gnome-common's gnome-autogen.sh.
Comment 37 Christian Kirbach 2005-12-12 00:12:58 UTC
Created attachment 55873 [details] [review]
default to automake 1.9 instead of 1.4
Comment 38 James Henstridge 2005-12-12 01:21:05 UTC
Christian: are you saying that you were able to successfully run "make
distcheck" on the automake-1.4 modules in Gnome 2.12 with this patch applied?

If you have not done that, then you have not checked to see whether it breaks
things.
Comment 39 Christian Kirbach 2005-12-12 10:16:13 UTC
No, I was running "jhbuild build" on almost all modules (except Evolution*).

But I will have a script run "make distcheck" in every module dir now that does 
not specify "REQUIRED_AUTOMAKE_VERSION=" in autogen.sh, i.e. the automake 1.4 
modules.
Comment 40 James Henstridge 2005-12-12 11:38:57 UTC
To help push this along, I updated libgtop and procman to Automake 1.9 today. 
While they both built with modern Automake, neither successfully distchecked
without some extra effort.

This discussion is getting a bit off topic for this particular bug though. 
Please subscribe to bug 323868 if you want to continue the discussion.
Comment 41 Rodney Dawes 2005-12-16 15:00:51 UTC
I'm lowering the priority on this. It is not in a released version of the
package, and I've implemented jamesh's suggestion for checking the version of
automake in intltool.m4, in CVS. I'm leaving this bug open though, as it would
be nice if we could work with automake 1.4 again in some way. It needs to be
investigated a bit though.
Comment 42 Nickolay V. Shmyrev 2005-12-24 16:30:42 UTC
*** Bug 322586 has been marked as a duplicate of this bug. ***
Comment 43 Nickolay V. Shmyrev 2005-12-24 16:31:52 UTC
*** Bug 322584 has been marked as a duplicate of this bug. ***
Comment 44 Charles Kerr 2006-04-04 15:11:12 UTC
*** Bug 336694 has been marked as a duplicate of this bug. ***
Comment 45 Danilo Segan 2007-07-20 22:29:21 UTC
Rodney, had this changed in the last 18 months? You still plan to support automake 1.4, or are we to OBSOLETE this bug?
Comment 46 Rodney Dawes 2007-08-03 00:07:23 UTC
I think it's safe to obsolete it now.